[MITgcm-devel] Unrealistic low SST with SEAICE_GROWTH_LEGACY undef

[Gael Forget]

Hi Dimitris,

I dont have a strong preference regarding names but interior_freeze may be 
just fine (item 1) and item 3 likely should be done before anything else.

As far as item 2 the new package should be made to work independently of pkg/thsice and pkg/seaice first (and of kpp please).
Basically I suggest you start with
	=> A 2D array containing negative heat in "Joules" will be generated that will be added to Qnet.
	=> allowFreezing rather than more complex ice models, and convective adjustement rather than kpp.
It would be nice to add a switch to decide whether the needed heat should be taken from the ocean first layer (as it is now I believe) 
or in the atmosphere (where your plan takes at least some of it). And it should be possible for the user to back out the
ocean conservation of heat (or the lack thereof) using pkg/diagnostics. Those points seem like obvious pre-requisites
to a discussion of whether a refined integration in ice models is worth it and of interest. If you decide to forego those intermediate steps, 
I would suggest you go all the way and start with pkg/thsice rather than pkg/seaice -- with the better ice conservation principle that is.

Cheers,
Gael

On Feb 15, 2012, at 10:09 AM, Menemenlis, Dimitris (3248) wrote:

> Jean-Michel (and other MITgcm swimmers who are disturbed by cold sea-water temperatures),
> I summarize a conversation with Ian following JM's last message:
> 
> 1. As Chris and JM have suggested, I plan to package interior_freeze.
>   There's many reasons for that, including the addition of diagnostics and the potential
>   for a more realistic description of frazil ice formation and redistribution processes at depth.
> 
> ??? What should this package be called: pkg/ifreeze, pkg/frazil, other suggestions?
> 
> 2. Initially pkg/frazil will only do what interior_freeze does now, i.e., collect negative heat below the freezing point at depth and immediately bring it to the surface.  Temperatures below the freezing point at depth will be adjusted to the freezing point.  A 2D array containing negative heat in "Joules" will be generated, which will be passed first to the sea-ice and shelf-ice packages.  Any residual heat after the "ice" packages are done, will be divided by RAC and dTtracerLev(1) and added to Qnet.
> 
> ??? Should pkg/frazil collect negative heat from the surface level,
> ??? from the level immediately below ice shelves,
> ??? or from grid boxes adjacent to ice fronts?
> 
> 3. I will generate 2 separate diagnostics:
>   a 3-D diagnostic that contains pkg/frazil temperature adjustments divided by dTtracerLev(k) in deg C / s,
>   and a 2-D diagnostic that contains the negative heat passed to the ice packages in Joules.
> 
> Let me know if above sounds reasonable, any additional suggestions or requests,
> and whether to proceed with packaging of interior_freeze.
> 
> Thanks
> 
> Dimitris Menemenlis
> 
> On Feb 6, 2012, at 6:44 PM, Jean-Michel Campin wrote:
> 
>> Hi Dimitris and Ian,
>> 
>> It seems to me that what you are proposing is still acting
>> like an adjustment (point 3), and in this case, it's probably
>> better not to put it into the tendency (so that it will not
>> go through AB), but to leave as it is now (like convective
>> adjustment). 
>> However, if it does not reset temp < freezing to freezing, but involves
>> some time-scale, then it can be added as a tendency.
>> 
>> But if you feel like this interior-freezing is going to complexify 
>> and evolve so that it involves more terms (time-scale, parameters, 
>> array to carry to model/src routines), might be a good idea to make 
>> a new pkg (this is what Chris suggested last April).
>> 
>> I added some specific comment below.
>> 
>> On Mon, Feb 06, 2012 at 11:57:26AM -0800, Menemenlis, Dimitris (3248) wrote:
>>> Jean-Michel, we need your advice on how to proceed.
>>> 
>>> Right now interior_freeze redistributes heat from surface to
>>> depth by changing theta directly.
>>> This is not very good coding because (i) it can (and has) lead
>>> to confusion and (ii) it bypasses the tendency term computations.
>>> 
>>> Ian and I can reformulate freeze_interior.F as follows:
>>> 
>>> 1. create a routine called INTERNAL_FORCING_T
>>> (modeled on EXTERNAL_FORCING_T) and call it
>>> within CALC_GT.F
>> I don't see why we need an other S/R like this. Most of the pkgs add
>> their (2.d or 3.d) contributions within external_forcing.F (U,V,T,S), such as 
>> atmospherics physics pkgs, so it seems to me that this will just create
>> confusion. 
>> 
>>> 2. INTERIOR_FREEZE will be the first contribution
>>> to INTERNAL_FORCING_T and will parameterize the
>>> formation of marine ice in cavities and platelet or frazil
>>> ice at depth in the open ocean.
>> I have problems to follow: do you mean the routine INTERNAL_FORCING_T
>> you mentionned just above ? CALC_GT is called within a k-loop,
>> so might be less easy to call INTERIOR_FREEZE within a k loop, no ?
>> 
>>> 3. at depth, INTERIOR_FREEZE will compute and add temperature tendency
>>> contributions according to the assumption that water temperature
>>> never goes below the pressure and salinity dependent freezing point.
>> 
>> This does not look very different from what we have now (freeze_interior.F), 
>> right ? BTW, would be nice to have (at least a 2-D diag of how much surface
>> cooling is produced by S/R FREEZE_INTERIOR).
>> 
>>> 4. at the surface level, there will be two options:
>>> 
>>> if  useSEAICE = .FALSE.
>>> we provide a negative temperature flux that may cause surface level
>>> temperature to drop below surface level freezing point
>>> 
>>> id useSEAICE = .TRUE.
>>> we provide a d_HbyInteriorFreeze
>>> that is, an addition to ice thickness, to be dealt with by pkg/seaice
>> 
>> I agree with this "surface level" improvement (But Gael is ready to make
>> some cleaning in seaice_growth, so may be better to wait until he is done),
>> which would go also along Martin's suggestion.
>> 
>>> 5. We are not going to worry about vertical salt transports for the time
>>> being, because we don't know what they are.  This is equivalent to
>>> assuming that the rising ice slush changes with its environment.
>> It looks like there is some potential for an other pkg !
>> 
>> Cheers,
>> Jean-Michel
>> 
>>> 
>>> Let us know if this is a good way to proceed,
>>> 
>>> Ian and Dimitris
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20120215/33784b5e/attachment.htm>