[MITgcm-devel] inconsistencies with density conversion factors in sea ice growth

Tue Apr 19 11:26:49 EDT 2011

Go for it, I had meant to do something like this for a long time, but never was brave enough to do so, because I didn't want to break any set ups.

Martin

On Apr 19, 2011, at 4:21 PM, Jean-Michel Campin wrote:

> Hi Ian and others,
> 
> I tend to agree.
> 
> I would propose a 2 steps change (so that we know what is causing what):
> 1) first step: remove ICE2WATR from all verification/input*/data.seaice :
> was added on Nov 29, 2007:
>> Changed ICE2WATR to SEAICE_rhoIce/rhoConst for consistency between
>> dynamics and thermodynamics of pkg/seaice.
>> Set ICE2WATR=0.92 to reproduce old output.txt in verification experiments.
>> http://forge.csail.mit.edu/pipermail/mitgcm-devel/2007-October/003053.html
> Unfortunately, it looks like setting "ICE2WATR=0.92" has become quite
> popular even after Nov 29, 2007 (seaice_obcs/input/data.seaice,
>  all lab_sea/*/data.seaice, 1D_ocean_ice_column/*/data.seaice ...)
> May be take this opportunity to use other meaningful defaults
>  instead of some "funny constants" in data.seaice, since we will have to
>  generate new outputs anyway.
> 
> 2) 2nd step: fix saltFlux rhoConst things (in fact, there is no needs
>  for any water-density conversion factor in saltFlux expression).
> Requires a 2nd update of verification exp that use salty seaice.
> 
> And when things are well settled, can remove ICE2WATR from seaice namelist.
> 
> What do others think ?
> 
> Cheers,
> Jean-Michel
> 
> On Tue, Apr 19, 2011 at 10:16:45AM -0400, Jean-Michel Campin wrote:
>> I though this email from Ian was sent to devel list... 
>> So I fwd it.
>> Jean-Michel
>> ----- Forwarded message from "Fenty, Ian G (3248-Affiliate)" <Ian.Fenty at jpl.nasa.gov> -----
>> 
>> Date: Mon, 18 Apr 2011 13:24:48 -0700
>> From: "Fenty, Ian G (3248-Affiliate)" <Ian.Fenty at jpl.nasa.gov>
>> To: Campin Jean-Michel <jmc at ocean.mit.edu>
>> Subject: inconsistencies with density conversion factors in sea ice growth
>> 
>> Hello devel,
>> 
>> Examining how seaice_growth handles salt fluxes when sea ice salinity equals the local seawater salinity (SEAICE_salinity = 1) revealed a potentially serious problem.  As the code is currently written, salinity is not conserved after completing a growth-melt cycle provided we use SEAICE_SALINITY and SEAICE_salinity > 0.
>> 
>> The problem can be traced to different parts of seaice_growth that contribute to surfaceForcingS: EmPmR and saltFlux.
>> 
>> ***** EMPMR
>> 
>> As far as I can tell, the contribution of ice to EmPmR is defined correctly.  As I understand the logic, knowing the effective ice thickness delta, dHEFF, we can calculate an equivalent freshwater depth (approximately equivalent to the salty water depth as salt doesn't appreciably add to the liquid volume).  A freshwater mass flux can be calculated from the the freshwater depth delta:
>> 
>> EmPmR (kg /m^2 /s ) = dHEFF * [SEAICE_rhoIce / rhoConstFresh] / SEAICE_deltaTtherm  * rhoConstFresh
>> 
>> Where dHEFF * [SEAICE_density / rhoConstFresh] is the equivalent depth of melted freshwater that's in the ice and the final multiplication of rhoConstFresh converts to a mass flux.
>> 
>> or, more simply:
>> 
>> EmPmR = dHEFF * SEAICE_rhoICE / SEAICE_deltaTtherm
>> 
>> 
>> *****  SALTFLUX
>> 
>> The equation for saltFlux is probably incorrect.  It is defined as psu kg /m^2 / s -  or when S is expressed in g/kg  as  g / m^2 / s.  It's easier to think about it if one considers S as a mass ratio, g/kg.
>> 
>> To calculate saltFlux we use the seawater mass flux and the salinity mass ratio:
>> 
>> saltFlux (g/ m^2 /s) = m_sw / SEAICE_deltaTtherm * SEAICE_salinity * SALT
>>                               [kg / m^2]     [s^-1]                    [unitless ]   [g/kg]  -- > [g /m^2 /s]
>> 
>> Where m_sw is the mass of seawater that is converted into ice per m^2,  SEAICE_salinity is a fraction (0..1) of the local salinity that the sea ice is going to have, and SALT is the local salinity.
>> 
>> The converted seawater mass can be written in terms of dHEFF:
>> 
>> m_sw = dHEFF * SEAICE_rhoIce
>> 
>> so saltFlux becomes:
>> 
>> saltFlux = dHEFF * SEAICE_rhoIce / SEAICE_deltaTtherm  * SEAICE_salinity * SALT
>> 
>> 
>> In the code, it is actually defined as:
>> 
>> saltFlux = dHEFF * ICE2WATR * rhoConstFresh / SEAICE_deltaTtherm * SEAICE_salinity * SALT
>> 
>> With ICE2WATR being a run-time parameter with a default value of:
>> 
>> ICE2WATR = SEAICE_rhoIce*recip_rhoConst
>> 
>> 
>> **** SUMMARY
>> 
>> The magnitudes of the salinity contributions from EmPmR and saltFlux will incorrectly differ by the ratio SEAICE_salinity* rhoConstFresh/rhoConst instead of just SEAICE_salinity because of an inconsistency in the calculation of saltFlux.
>> 
>> This error will not be seen if SEAICE_SALINITY is undefined or if SEAICE_salinity = 0.
>> 
>> 
>> **** RECOMMENDATIONS
>> 
>> #1) rhoConstFresh should be removed from the saltFlux equation.  If we want to be explicit, we must use rhoConst instead.  Alternatively, ICE2WATR can be removed and the equation simplified to:
>> 
>> saltFlux = dHEFF * SEAICE_rhoIce / SEAICE_deltaTtherm * SEAICE_salinity * SALT
>> 
>> #2)  ICE2WATR should be removed as a separate run-time parameter.  So long as it is specified as being anything but SEAICE_rhoICE * recip_rhoConst, salinity will not be conserved with SEAICE_SALINITY.  The reason for the conservation violation is that EmPmR will extract the correct amount of freshwater but saltFlux won't remove the correct amount of salt.  ICE2WATR is only used in the saltFlux calculation and it's removal will probably not be missed.
>> 
>> Of course, fixing this bug will lead to verification experiment failures.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ----- End forwarded message -----
>> 
>> _______________________________________________
>> 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