[MITgcm-devel] inconsistencies with density conversion

[Ian Fenty]

Jean-Michel,

On Apr 27, 2011, at 6:56 AM, Jean-Michel Campin wrote:

> As for step.3:
> a) should we delay the removing of ICE2WATR for /SEAICE_PARM01/ namelist ?
> the idea is that allowing some time (couple a checkpointXX) between the time
> when it was removed from many data.seaice and the time when it's removed
> from the namelist is probably not too bad.

As of now, ICE2WATR has been stripped out of all of the code and is only initialized.  Is there a system for scheduling the variable removal - a variables-to-be-removed list somewhere that is periodically cleared?  If not, I know I will soon forget all about ICE2WATR and, if removing it in several checkpoint were left to me, ICE2WATR will just ride along, doing nothing but taking up space in the source, like a bit of junk DNA, forever.

> (+ my impression is that having SEAICE_lhSublim <> SEAICE_lhFusion+SEAICE_lhEvap
> is not consistent and break the heat budget ? can this be confirmed ?

The energy required to sublimate ice is the same as the energy required to first melt and then vaporize (even though ice does not pass through a liquid phase on the way).  It's actually one of those easily forgotten basic physical principals: the enthalpy of the vapor less the enthalpy of the ice is equal to the enthalpy required to melt the ice plus the enthalpy required to evaporate the water.  

So, like ICE2WATR, there shouldn't be an explicit lhSublim variable; we should always add SEAICE_lhFusion and SEAICE_lhEvap.  Otherwise, we will be spuriously adding or removing energy when going through phase transitions.

> in this case, could be also removed from namelist when ICE2WATR is removed)

most definitely.

> b) renaming things can be done now.
> The treatment of "retired parameters" in seaice-readparams.F is already
> in place so should be  straitforward.

excellent.

-Ian