[MITgcm-devel] inconsistencies with density conversion

[Ian Fenty]

>> 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.
> 
> not completely sure about this (in seaice_init_varia.F ?)


Oh god, you're right.  It was used to initialize ice salinity.  It has to removed from there as well, and that might change the verification results yet again.

> 
>>> (+ 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.  
> 
> I think it's coded right in pkg/thsice (but does not check if latent
> heat of fusion has the same value across pkgs thsice / exf / bulk_force)


Is there a good reason to use different values of the latent heat of fusion and evaporation across different packages?  

> 
>> 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.
> 

> A little question here: the default value for SEAICE_lhSublim is "not always"
> SEAICE_lhFusion+SEAICE_lhEvap, but only when the default values of 
> SEAICE_lhEvap & SEAICE_lhFusion are used (or flamb & flami from EXF).
> May be worth to change first the default value of SEAICE_lhSublim
> with something like:
> 
> SEAICE_lhSublim = UNSET_RL
> read-namelist
> IF ( SEAICE_lhSublim.EQ.UNSET_RL ) SEAICE_lhSublim = SEAICE_lhFusion+SEAICE_lhEvap
> 

Right, it's somewhat like ICE2WATR in that if it is UNSET_RL then it gets a sensible default value (although ICE2WATR's default value was itself slightly wrong) but if it *is* set then other things will or may break.  If in one place we use SEAICE_lhEVAP to condense and SEAICE_lhFusion to freeze and in another place we use SEAICE_lhSublim to sublimate, then energy won't be conserved between ice-vapor phase changes.  

My philosophy is that we should reduce the number of possible instances where conservations laws can break.  Because we already require and use lhFusion and lhEvap separately (although they may actually be set differently in EXF and thsice), there is no reason to permit a separate (and therefore possibly physically inconsistent) run-time specification of their sum.  But that's just my 2c.

-Ian