[MITgcm-devel] Unrealistic low SST with SEAICE_GROWTH_LEGACY undef

[Martin Losch]

Hi Gael,

I just wanted to avoid any confusion, and emails tend to "not" get the connotations across. I guess it's best to discuss these matters face to face.

Your plans sounds good to me, and removing all or most of these CPP flags is also very honorable.

Martin

On Feb 8, 2012, at 5:18 PM, Gael Forget wrote:

> Martin,
> 
> sorry for not being clear enough. I tried to be so. In particular
> my reference to you in the first sentence was meant to apply 
> only to that sentence, with which you seem to agree somewhat.
> The rest was my tentative summary of a 20 pages (loose count) thread (that 
> was what I meant by "bottom line"), and I reckon it reflects some of my 
> opinions ("in my view"). Also I was told I was a little stiff in that summary 
> email. And, for the record I was not arguing in favor of using either 
> CAP_HEFF,  freeze_interior, or MCPHEE_OCEAN_ICE_HEAT_FLUX. 
>> I guess that's something to discuss in three weeks, when we (some of us) meet in Boston.
> agreed. I plan to run more sensitivity tests, outside of testreport by then, fwd and ad.
> I will start after clean-up sweep is "complete" because its do painful when
> I constantly need to recompile the model (CPPs vs run time params). 
> Is this a plan you would follow?
> 
> Cheers,
> Gael
> 
> On Feb 7, 2012, at 7:56 AM, Martin Losch wrote:
> 
>> Hi there, 
>> 
>> from the "seaice clean up this week" thread:
>>> As far as the runaway T thread, it seems pretty clear (as stated by Martin's) that what makes 
>>> seaice_growth most unsafe is omitting the turbulent flux for freezing. There is a variety 
>>> of ocean and ice parameter sets that will likely create instances of 'slightly' below freezing T. 
>>> Non flux limited advection schemes and the CAP_HEFF stuff to start with, and then there is the 
>>> variety of hypotheses you guys discussed. Martin caught one that is now thought to be related 
>>> to allowInteriorFreezing. Chasing this one down is probably useful. It wont save us the next time 
>>> somebody else gets in the same situation for a different reason though. Fortunately including 
>>> turbulent flux for freezing makes it safe, or at least much safer. In my view that's the bottom line.
>> Just to be clear about my previous post:
>> I agree that using the turbulent flux for freezing (#undef MCPHEE_OCEAN_ICE_HEAT_FLUX) fixes the problem of surface temperatures below freezing, thus stabilizing seaice_growth. 
>> But I do not agree that this parameterization should be used as a safeguard against all sorts of (numerical or algorithmic) problems that sometimes cause temperatures below freezing. As an example, with the seaice-legacy code, this safeguard does not prevent low temperatures (-5degC) in my configuration. Instead we should find physcially motivated parameterizations that avoid temperatures below freezing, or fix these low temperatures in a physically consistent way. In this context, the freeze_interior routine or the CAP_HEFF are good examples of how *not* to do it (and this does not mean that I blame anyone introducing this code, I did my own share, I guess). Rather than keeping this code, we should probably push ourselves towards using MCPHEE_OCEAN_ICE_HEAT_FLUX by default, so that we run into problems that are caused by code that is "unphysical", and are forced to fix these. (E.g., I never thought that freeze_interior could have the effect that it had in my configuration
 .
> )
>> I guess that's something to discuss in three weeks, when we (some of us) meet in Boston.
>> 
>> Martin
>> 
>> 
>> _______________________________________________
>> 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