[MITgcm-devel] Unrealistic low SST with SEAICE_GROWTH_LEGACY undef

Mon Feb 6 14:57:26 EST 2012

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

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.

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.

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

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.

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