[MITgcm-devel] Unrealistic low SST with SEAICE_GROWTH_LEGACY undef
Martin Losch
Martin.Losch at awi.de
Tue Feb 7 07:56:16 EST 2012
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
More information about the MITgcm-devel
mailing list