[MITgcm-devel] MITgcm-devel Digest, Vol 91, Issue 8

[Ian Fenty]

Gael:
In response to your two posts in devel:

************************************************************************************************
>> I think I am ready to check the McPhee part in, but before I do so, I have a few questions:
>>- I am not clear why you use hfacc and not maskc. It seems to imply
>> that the friction velocity depends on the layer thickness. Is this by design?
************************************************************************************************

You are right, that should be maskc.

************************************************************************************************
>>- the GRADIENT_MIXED_LAYER_TURBULENCE_FACTOR seems more
>> appealing that the step function approach. Should't we make the continuous
>> approach the default? Would anybody use the step function approach?
************************************************************************************************

Well, I agree with you.  I didn't make it the default because it's not in the original *_if code and I didn't want to confuse myself too much.  Really neither approach is great, but the continuous approach is better for the adjoint.  Ultimately, we should try to figure out a better way of getting u* than just setting two fixed values and interpolating between them base on AREA.

************************************************************************************************
>>- dont we want to do something in the case of T<T freezing? A situtation that 
>> will likely happen e.g. due to advection overshoots. Am I missing something?
************************************************************************************************

Hmm….  Mixing and radiation always bring T above T_freezing eventually.  If one considers the upper ocean grid cell to have an unresolved spatial distribution of heat, one might want to "freeze" some of the artificially supercooled water and leave T = T_freezing + epsilon.  That would probably be better for the adjoint.  

Advection overshoots aren't the only source of T < T_freeze.  Water rising from beneath or along ice shelves might be supercooled upon reaching the surface due to the freezing point's pressure dependence.  How we handle those supercooled waters is an open question.   Should we simply add volume to existing ice while leaving the area unchanged or should we allow new ice to expand the ice cover?  If the latter, should we use the open water growth factor h0 to determine the new area increment or should we use some the other parameterization?  I'm not sure what's best.

************************************************************************************************
>>I attach a slightly edited version of your routine (try diffing the two), to
>>facilitate comparisons with the latest pkg/seaice. 
************************************************************************************************

Reasonable people can disagree about whether seaice_growth rev 1.112 is a slightly edited version of what I put in the contrib.

************************************************************************************************
>> The edits I made were:
>>	- remove the QSW term you added to QNET (was breaking heat conservation)
************************************************************************************************

I'd like to see how heat conservation is broken.  Unless I'm seriously mistaken or unless things changed, that term is required for the properly calculation of surface temperature tendency.  I'll try to describe my reasoning.   If I'm missing something here, I beg to be enlightened.

Before the model goes into sea ice growth, QNET is defined like:

QNET = non-shortwave radiative air-sea heat fluxes + QSW

Without any sea ice, the temperature tendency at k =1 takes QNET and subtracts out the total heat flux convergence due to QSW from level k=2 to infinity to properly account for the heat fluxes in the upper ocean grid cell.  In other words,

\partial THETA(k=1) / \partial t = Constants * [ QNET - QSW_converging_below_surface ]

When my code blocks are defined, I do nothing with the QSW that penetrates the sea ice , a_QSWbyATM_cover, in the sense that I don't use it to melt ice nor to inhibit ice formation.  Note, however that a_QSWbyATM_cover is included in the redefinition of QSW at the end of the routine:

QSW(I,J,bi,bj)  = a_QSWbyATM_cover(I,J) + a_QSWbyATM_open(I,J)

It is entirely possible that at the end of sea ice growth QNET=0 (e.g., all open water surface heat fluxes, ice conductive fluxes, and turbulent ocean-ice fluxes are exactly offset by changes in ice energy).  In such a case, the eventual subtraction of QSW_converging_below_surface in the temperature tendency equation will cause the model to think that there is a net energy flux divergence in the upper ocean grid cell which will consequently (and incorrectly) reduce the temperature of that cell - even far below the freezing point.  In the way I designed the logic, any QSW converging in the uppermost grid cell should serve as a positive contribution to uppermost cell temperature.

I don't want to get into a discussion about how you determine heat conservation.  I will point out, however, that in the version of seaice_growth that I modified, you used a_QSWbyATM_cover  to calculate d_HEFFbyATMonOCN_open (I think it a little odd that shortwave penetration beneath ice modifies a variable whose name implies it considers fluxes from the ice-free "open" ocean, but we can leave the consistency of variable names to another discussion).  Therefore, I believe that's was where you were accounting for that flux previously.  

But again, that's not how I'm doing it, so I think a_QSWbyATM_cover should be added to QNET.  
   
************************************************************************************************
>>	- fix the d_HEFFbyATMonICE stuff (was breaking global_ocean.cs32x15)
************************************************************************************************

If a variable I added "broke" something, then it was because I couldn't see how it could possibly change the results and therefore didn't wrap it in an ifdef block.  After looking at it again, I still can't imagine how adding d_HEFFbyATMonICE changes anything, but if it does then I'll simply do some more wrapping in ifdef statements.  I didn't add that variable arbitrarily - I need the contributions to ice thickness tendency to be clearly split between the component coming from atmospheric fluxes over the snow/ice surface and the component coming from atmospheric component over the ice-free surface.

************************************************************************************************
>>	- replace '*AREApreTH(I,J)/heff_star' with '/heffActual(I,J)' (no need for extra var)
************************************************************************************************

I want heff_star to be separate from heffActual.  The minimum heffActual allowed (hiceMin) used for conductive fluxes needn't necessarily be the same as the minimum thickness for ice concentration tendency.  Plus, for the adjoint, heff_star smoothly approaches 0.10 cm as heff --> 0 whereas heffActual is a step function.

************************************************************************************************
>>>	- replace my SEAICE_DO_OPEN_WATER_GROWTH block with yours (as done in rev1.111)
>>>	- define SEAICE_OCN_MELT_ACT_ON_AREA (since I removed the undef case in rev1.112)
************************************************************************************************

I don't want to comment on changes you might want to make to the default behavior of the model.  First, let's put my changes in the code behind ifdef blocks exactly as I wrote them, then we can make sure that the verification experiments that I made and put in contrib work, and then we can lock in the results. 

************************************************************************************************
>> Then, I did a series of global_ocean.cs32x15 forward runs to make sure that the
>> latest pkg/seaice and your latest contrib routine (with the above edits) give the same results,
>> for the following sets of CCP options:
>>	- FENTY_DELTA_HEFF_OPEN_WATER_FLUXES alone (default of global_ocean.cs32x15).
>>	- FENTY_AREA_EXPANSION_CONTRACTION alone (i.e. SEAICEareaFormula=3)
>>	- MCPHEE_OCEAN_ICE_HEAT_FLUX alone
>>	- all three + SEAICE_OCN_MELT_ACT_ON_AREA (i.e. SEAICE_DO_OPEN_WATER_MELT)
************************************************************************************************

In my email and pdf, I wrote:

* Because seaice growth.F is somewhat complicated, changing a parameterization often triggers changes to other parameterizations. Consequently, although the parameterizations are relatively self-contained, […] they are interdependent […] and will not work in isolation. *

So, being that all of the non-optional flags need to be turned on for my changes to work, I don't understand the experiments you are describing.  

************************************************************************************************
It would be great if you could re-run some of the tests you documented a couple weeks ago, and
let us know if you are unhappy with the results
************************************************************************************************

Being that what is there now cannot reproduce what I put together and posted to contrib, why would I rerun my verification experiments?  They are not only going to be different, but unphysical for the reasons I described above.

-Ian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110217/5fa17adb/attachment-0001.htm>