[MITgcm-devel] Unrealistic low SST with SEAICE_GROWTH_LEGACY undef

Mon Feb 6 23:28:31 EST 2012

Jean-Michel, thank you for answers and advice.
I will discuss with Ian on how he wants to proceed and get back.
We will definitely wait for Gael to be finished before we touch anything in pkg/seaice.

Cheers

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
>> 
>> On Feb 6, 2012, at 2:20 AM, Martin Losch wrote:
>> 
>>> Hi there,
>>> 
>>> Ian and I think that we found the culprit for the unrealistically low SST with the non-legacy code and MCPHEE_OCEAN_ICE_HEAT_FLUX. It appears that none of the code blocks that Ian described in his previous email make a significant contribution to these very low temperatures, although I agree that they have the potential to do so. 
>>> Instead by the usual trial-and-error procedure, the non-seaice-flag allowInteriorFreezing=.true., that I had set in order to avoid temperatures below freezing in the interior appear to be the culprit. Ian has a plausible explanation for this (I am citing from one of his emails to me, I hope with his consent):
>>> 
>>> "On the shelf [that's where the problem occurs] where ice production and salt rejection can be high, interior temperatures could end up being quite low and salinities quite high during winter.  When spring comes around and some of that ice melts and the freshwater mixes down, the interior freezing point can rise and the negative heat would then be applied to the surface where temperatures are at the freezing point.  If this happens repeatedly, surface temperatures could fall quite far."
>>> 
>>> S/R freeze_interior by-passes all heat flux considerations by moving any dTheta (by which theta is below local freezing) directly into the surface layer. This does not matter, when MCPHEE_OCEAN_ICE_HEAT_FLUX is not used, because (too) low temperatures are dealt with in the "old"/default parameterization of ocean melting (ll868-879 in the current seaice_growth.F, r1.147). But when MCPHEE_OCEAN_ICE_HEAT_FLUX is defined, the very negative surface temperatures (that stem from interior_freeze) cannot be (or rather, are not) used to form ice.
>>> 
>>> To some degree it is a matter of taste, how one deals with this (the very low temperatures). I think that
>>> 1. the non-legacy code apparently has a much more consistent treatment of heat fluxes, so that below-freezing temperatures rarely appear.
>>> 2. super-cooled water in the context of a "coarse" (grid cell width of a few km and more) is not very realistic (i.e., having supercooled water of a volume of e.g. 25^2km^2*10m = 6.25km^3). I observe occasional cold temperatures of order -5 degress with non-legacy code (independent of the above discussion), that go away with the non-legacy code (and the proper flag combination). Apparently the MCPHEE_OCEAN_ICE_HEAT_FLUX is consistent as long as there no extra local temperature sinks as in interior_freeze.F. Alternatively using the other method handles the low temperatures as well, but appears less physical (and has problem with the adjoint, if I understand properly).
>>> 3. "interior freezing" should be available, but it should be a parameterization that form "frazil ice" in the interior and moves that to the surface (either as a heat flux, or as ice). The simplest method I can think of is to "form" frazil ice (call the subroutine) before seaice and thsice, have it modify surface heat flux, maybe an extra 2D heat flux field that is added to both (in seaice_growth terminology) a_QbyATM_cover and a_QbyATM_open.
>>> 
>>> Greetings from freezing Bremerhaven (-10degC and less for over a week now. Today, cycling into work, tear-fluid (with salinity of about 9 => freezing point -0.5degC) froze on my glasses). Sea-ice on the river when I look out of the window ...
>>> 
>>> Martin
>>> 
>>> On Feb 3, 2012, at 9:20 PM, Ian Fenty wrote:
>>> 
>>>> Sea ice people,
>>>> 
>>>> After looking at Martin's output, I (tentatively) verified that actual thermodynamical ice processes are working fine and that nothing thermodynamical is driving T < T_freeze.  However, I did find two non-thermodynamical extraneous code blocks which can cause temps to fall below T_f.  Allow me to point them out.
>>>> 
>>>> Culprit 1)  When ice is very thin, we melt whatever ice and snow volume is present using ocean enthalpy, regardless of whether any energy is actually available to melt:
>>>> 
>>>> 429  C 1.25) treat the case of very thin ice:
>>>> 
>>>> 438     if (HEFF(I,J,bi,bj).LE.siEps) then
>>>> 439        tmpscal2=-HEFF(I,J,bi,bj)
>>>> 440        tmpscal3=-HSNOW(I,J,bi,bj)
>>>> 441        TICE(I,J,bi,bj)=celsius2K
>>>> 442     endif
>>>> 
>>>> 443     HEFF(I,J,bi,bj)=HEFF(I,J,bi,bj)+tmpscal2
>>>> 444     d_HEFFbyNEG(I,J)=d_HEFFbyNEG(I,J)+tmpscal2
>>>> 445     HSNOW(I,J,bi,bj)=HSNOW(I,J,bi,bj)+tmpscal3
>>>> 446     d_HSNWbyNEG(I,J)=d_HSNWbyNEG(I,J)+tmpscal3
>>>> 
>>>> Culprit 2) Remove HEFF when it is too large by melting, regardless of whether any energy is actually available to melt:
>>>> 
>>>> 1446     #ifdef SEAICE_CAP_HEFF
>>>> 1447        C This is not energy conserving, but at least it conserves fresh water
>>>> 1448        tmpscal0 = -MAX(HEFF(I,J,bi,bj)-MAX_HEFF,0. _d 0)
>>>> 1449        d_HEFFbyNeg(I,J) = d_HEFFbyNeg(I,J) + tmpscal0
>>>> 1450        HEFF(I,J,bi,bj) = HEFF(I,J,bi,bj) + tmpscal0
>>>> 1451     #endif /* SEAICE_CAP_HEFF */
>>>> 
>>>> Both of these code blocks can cause heat loss from the surface grid cell when T <= T_freeze.
>>>> 
>>>> With respect to the first culprit, I argued earlier that it wasn't necessary but I failed to predict that it could actually lead to SST pathologies.  With respect to the second, I don't know 1) where it comes from, 2) why excessive HEFF is a thermodynamic issue (i.e. why this cap is in seaice_growth), or 3) why treating the problem of excessive HEFF is done via "not energy conserving" code.   
>>>> 
>>>> I also don't know whether these parts are responsible for the Martin's or anyone else's problem, although SEAICE_CAP_HEFF is defined in Gael's SEAICE_OPTIONS.h that he sent to the list.
>>>> 
>>>> Unless a cogent argument can be made for keeping the very thin ice "pathology", I suggest that we remove it or at least make it an option that must be explicitly specified.   For both the thin ice removal and the HEFF capping, I suggest that if either is done, we at least we do it without removing imaginary ocean heat.  If HEFF capping is related to some issue of dynamics, then I suggest that it be done elsewhere (perhaps a routine which prepares the ice field for the dynamics solver).  The more we dump code which isn't related to thermodynamic growth and the expansion and contraction of ice cover into seaice_growth, the harder and harder it becomes to read and debug.
>>>> 
>>>> -Ian
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel