[MITgcm-devel] inconsistencies with density conversion

[Jean-Michel Campin]

Hi Ian,

Sorry, it must be that I was not clear:

I prefer to group in step.1 the changes in data (rhoConstFresh)
and data.seaice (ICE2WATR + SEAICE_X values),
because this is all about getting better constants with the same code.

Then in step.2, changes in pkg/seaice/seaice_growth.F (to fix what
you spotted);

And renaming SEAICE_salinity (and/or SEAICE_VARIABLE_SALINITY) can be 
put in setp.3, because it's always anoying to rename parameters which 
are set in namelist (need to put them in "retired" list and
stop if they are found in data.seaice), and would need also to
stop if the old OPTION "SEAICE_SALINITY" is found to be defined.

But I don't know precisely when to do the checkpoint (I though
I would do it after step.1, but might see how thing are going).

Cheers,
Jean-Michel

On Mon, Apr 25, 2011 at 07:23:51AM -0700, Fenty, Ian G (3248-Affiliate) wrote:
> Jean-Michel,
> 
> Yeah, I misunderstood your email.  I thought you asked me to remove those default files after step 2, my plan was not to add a rhoConstFresh to those experiments that used sea ice, and I thought that you wanted to checkpoint after I fixed the bug in the seaice_growth.  
> 
> If you agree, I'll add rhoConstFresh to the data of sea ice experiments, remove those SEAICE_X values from those data.seaice files, and check in the fixed seaice_growth.F.  We can call that all of that step 2 then checkpoint.
> 
> Sound ok?
> 
> -Ian
> 
> 
> 
> 
> 
> 
> On Apr 23, 2011, at 8:45 AM, Jean-Michel Campin wrote:
> 
> > Hi Ian,
> > 
> > I did not find an answer to this email (so that I though we all
> > agree), but looking at the changes you made yesterday, does not
> > look like we had the same thing in mind:
> > You did remove ICE2WATR from all the data.seaice, but you did 
> > not remove (from the same data.seaice files) those "3 other defaults".
> > I though this was part of step.1:
> > http://mitgcm.org/pipermail/mitgcm-devel/2011-April/004646.html
> > 
> > Also, I did not see an explicit setting of rhoConsfresh beeing 
> > added to some "data" parameter files for those experiment using seaice.
> > (but not sure if it's part or your plan).
> > 
> > Can you tell us were we are going ? 
> > 
> > In the mean time, checkpoint62w is postponed.
> > 
> > Jean-Michel
> > 
> > On Tue, Apr 19, 2011 at 02:31:20PM -0400, Jean-Michel Campin wrote:
> >> Hi Ian,
> >> 
> >> few comments:
> >> 1) the 3 other defaults (in several data.seaice) I had in mind were:
> >> # for backward compatibility only:
> >> SEAICE_cpAir       = 1.0039560439560439e+03,
> >> SEAICE_lhSublim    = 2.8340219780219775e+06,
> >> SEAICE_rhoAir      = 1.3E0,
> >> 
> >> 2) would be good to allow > 24.h between step.1 and step.2, so that we 
> >> would get most of the testreport results.
> >> (and for west-coast people, if we can avoid to check-in things between
> >>  mid-night and 1.am Eastern time, this the time when the daily tag is done
> >>  + when most of the automatic test download the code).
> >> 
> >> 3) renaming variables/CPP-options could be done separately from the 2 other 
> >> steps. 
> >> 
> >> 4) not so much in favour of changing rhoConstFresh default, at least not
> >> now. But can re-consider it later.
> >> And if some of the experiment which will need updated output
> >> don't have rhoConstFreh set to a good value, it can be added in "data"
> >> 
> >> Cheers,
> >> Jean-Michel
> >> 
> >> On Tue, Apr 19, 2011 at 11:00:04AM -0700, Ian Fenty wrote:
> >>> Devel,
> >>> 
> >>> I will proceed as J-M proposes, first removing ICE2WATR from all the verification data.seaice files and then rewriting the saltFlux equation and, if possible, removing ICE2WATR altogether.  
> >>> 
> >>> I agree with the suggestion to take this as an opportunity to "use other meaningful defaults" and the use more transparent variable names.  
> >>> 
> >>> Specifically, the compile-time parameter SEAICE_SALINITY is misleading because it doesn't need to be defined for a nonzero ice salinity (e.g., SIsal0 specifies a constant ice salinity outside of SEAICE_SALINITY).  Also, Gael is quite right about the name of the run-time parameter SEAICE_salinity being misleading because it is not the seaice bulk salinity one might think, but actually a ratio.  Therefore, I propose changing SEAICE_SALINITY to SEAICE_VARIABLE_SALINITY (making a fixed seaice bulk salinity of SIsal0 the default) and using Gael's suggestion of changing SEAICE_salinity to SIsalFRAC.
> >>> 
> >>> Another example of using 'other meaningful defaults' is rhoConstFresh.  One of the reasons the sea ice salinity bug didn't pop up in budget-closing calculations is that the freshwater reference density is equal to seawater reference density by default.  From set_defaults.F:
> >>> 
> >>> C-- jmc : the default is to set rhoConstFresh to rhoConst (=rhoNil by default)
> >>> C         (so that the default produces same results as before)
> >>> c     rhoConstFresh       = 999.8 _d 0
> >>> 
> >>> And from ini_params.F:
> >>>      IF ( rhoConstFresh .EQ. UNSET_RL ) rhoConstFresh=rhoConst
> >>> 
> >>> Perhaps it is also time to allow the default reference freshwater density to be 999.8 kg/m^3 (the actual freshwater density at about 20 deg C).  If old results need to be reproduced, a different rhoConstFresh value can just be set in 'data'.    rhoConstFresh is used in the bulk formula equations so one would expect that using a more accurate number would reduce errors in EmPmR and buoyancy forcing. 
> >>> 
> >>> what do we think about that? 
> >>> 
> >>> -Ian
> >>> 
> >> 
> >>> _______________________________________________
> >>> 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
>