[MITgcm-devel] horiVertRatio in forcing

Jean-Michel Campin jmc at ocean.mit.edu
Fri Dec 5 10:02:51 EST 2003


For different input-files units, I would prefer to make
the conversion
input-file unit -> standard forcing unit
in the loading phase, according to what ncdf files tell.

But after, we still need to convert
standard forcing unit -> model tendency (in extern_forc_surf)
and it's not the ncdf input file that will tell us if
the model is in p or z coordinate. It's the reason why
(I think) this mass2rzVolume idea will still be there
with ncdf input files.

Jean-Michel
On Fri, 5 Dec 2003, Alistair Adcroft wrote:

> Once netcdf is available we will allow forcing fields to be in either
> densities or concentrations and the conversion be handled. J-M and I agreed
> it's nt worth sorting out before netcdf.
> 
> A.
> --
> Dr Alistair Adcroft            http://www.mit.edu/~adcroft
> MIT Climate Modeling Initiative        tel: (617) 253-5938
> EAPS 54-1523,  77 Massachusetts Ave,  Cambridge,  MA,  USA
> 
> -----Original Message-----
> From: mitgcm-devel-bounces at mitgcm.org
> [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Chris Hill
> Sent: Friday, December 05, 2003 9:41 AM
> To: MITgcm-devel at mitgcm.org
> Subject: RE: [MITgcm-devel] horiVertRatio in forcing
> 
> 
> Shouldn't we use a special notation to qualify density units of the
> input/output quantities (which may not always be w.r.t v[m,m,m] I guess)? We
> call the r based volume plain volume everywhere else in the model, so I find
> it odd to give it a qualified name here. Especially since it is not
> guaranteed that every input field we ever see will be provided wrt si unit
> volmes.
> 
> Chris 
> 
> > -----Original Message-----
> > From: mitgcm-devel-bounces at mitgcm.org 
> > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Alistair Adcroft
> > Sent: Friday, December 05, 2003 9:25 AM
> > To: MITgcm-devel at mitgcm.org
> > Subject: RE: [MITgcm-devel] horiVertRatio in forcing
> > 
> > We need to be able to distinguish between true density (mass / unit 
> > xyz
> > volume) and density in our coordinates (mass / unit xyr volume).
> > 
> > A.
> > --
> > Dr Alistair Adcroft            http://www.mit.edu/~adcroft
> > MIT Climate Modeling Initiative        tel: (617) 253-5938
> > EAPS 54-1523,  77 Massachusetts Ave,  Cambridge,  MA,  USA
> > 
> > -----Original Message-----
> > From: mitgcm-devel-bounces at mitgcm.org
> > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Chris Hill
> > Sent: Friday, December 05, 2003 9:16 AM
> > To: MITgcm-devel at mitgcm.org
> > Subject: RE: [MITgcm-devel] horiVertRatio in forcing
> > 
> > 
> > I don't get it :-)
> > 
> > When r->p we define our coordinate system as (m,m,pa) so volume has 
> > units m*m*pa When r->m we define our coordinate system as (m,m,m ) so 
> > volume has units m*m*m
> > 
> > So it is the mass per unit volume in our coordinate system - isn't it?
> > 
> > Chris
> > 
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: mitgcm-devel-bounces at mitgcm.org 
> > > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of
> > Alistair Adcroft
> > > Sent: Friday, December 05, 2003 9:00 AM
> > > To: MITgcm-devel at mitgcm.org
> > > Subject: RE: [MITgcm-devel] horiVertRatio in forcing
> > > 
> > > The "r" are in the names because it is the "density" in "r" 
> > > coordinates as opposed to mass per unit physical volume.
> > > 
> > > A.
> > > --
> > > Dr Alistair Adcroft            http://www.mit.edu/~adcroft
> > > MIT Climate Modeling Initiative        tel: (617) 253-5938
> > > EAPS 54-1523,  77 Massachusetts Ave,  Cambridge,  MA,  USA
> > > 
> > > -----Original Message-----
> > > From: mitgcm-devel-bounces at mitgcm.org
> > > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Chris Hill
> > > Sent: Friday, December 05, 2003 8:41 AM
> > > To: MITgcm-devel at mitgcm.org
> > > Subject: RE: [MITgcm-devel] horiVertRatio in forcing
> > > 
> > > 
> > > J-M
> > > 
> > > Do we need the r in the names. Why not m2v(k) and v2m(k)? I always 
> > > think of the volume as dx*dy*dr and letting the units be
> > whatever they
> > > are. Is that bad?
> > > 
> > > In general it would be really nice to tidy this up
> > everywhere into a
> > > form we all agree on. I've never liked horiVertRatio either (even 
> > > though I created
> > > it!) but I've never seen a better suggestion for how to
> > encode what we
> > > need. I would prefer something that we can apply consistently 
> > > everywhere. Not sure what it will be but I know it will make 
> > > Alistair's blood pressure rise to discuss it, which is always fun.
> > > 
> > > Chris
> > > 
> > > > -----Original Message-----
> > > > From: mitgcm-devel-bounces at mitgcm.org 
> > > > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of Jean-Michel 
> > > > Campin
> > > > Sent: Thursday, December 04, 2003 11:02 PM
> > > > To: MITgcm-devel at mitgcm.org
> > > > Subject: [MITgcm-devel] horiVertRatio in forcing
> > > > 
> > > > Hi,
> > > > 
> > > > I have a suggestion regarding horiVertRatio:
> > > > 
> > > > right now we have :
> > > > 
> > > > horiVertRatio = 1 (if r=z)
> > > > horiVertRatio = gravity*rhoConst (if r=p)
> > > > 
> > > > Since non-boussinesq (p-coordinate) does not need any constant
> > > > (reference) density, it's a litle curious to see rhoConst in the 
> > > > P-coordinate model, although, since horiVertRatio is
> > > (almost) always
> > > > used as horiVertRatio/rhoConst or
> > > rhoConst*recip_horiVertRatio, this
> > > > is not a real problem.
> > > > 
> > > > I propose (in a first step in external_forcing_surf only) to use:
> > > > 
> > > > mass2rVolum :: convert mass unit (kg) to "model" volume unit ( 
> > > > 1/"model density")
> > > >                so that: (dx*dy*dr)_unit = mass2rVolum * dMass_unit
> > > >                mass2rVolum = 1 / rhoConst (if r=z) ; = gravity (if
> > > > r=p) ; rVolum2mass :: convert "model" volume unit to mass
> > > unit (kg) (=
> > > > "model density")
> > > >                so that: dMass_unit = rVolum2mass * (dx*dy*dr)_unit
> > > >                = rhoConst (if r=z) ; = 1/gravity (if r=p) ;
> > > > 
> > > > The name for those 2 constants can change (althougth not too long 
> > > > would be better). But I think it could help to clarify the
> > > forcing and
> > > > diagnostic units.
> > > > 
> > > > I looked to other places where horiVertRatio is used, and
> > > seems to be
> > > > only in NonHydrostatic parts:  ini_cg3d.F  cg3d.F 
> > > > solve_for_pressure.F (NH part)  mom_u_coriolis_nh.F
> > > mom_u_metric_nh.F
> > > > mom_v_metric_nh.F
> > > > 
> > > > I think that we can leave those S/R as they are, because
> > > > a) in z coordinate, it's easy to remember that horiVertRatio=1.
> > > > b) it does not matter too much since P-coordinate cannot
> > > >    really be used with NonHydrostatic. horiVertRatio is
> > just there
> > > >    to make the units right, no more.
> > > > 
> > > > Any comment ?
> > > > 
> > > > Jean-Michel _______________________________________________
> > > > MITgcm-devel mailing list
> > > > MITgcm-devel at mitgcm.org 
> > > > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > > > 
> > > 
> > > _______________________________________________
> > > MITgcm-devel mailing list
> > > MITgcm-devel at mitgcm.org
> > > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > > 
> > > 
> > > _______________________________________________
> > > MITgcm-devel mailing list
> > > MITgcm-devel at mitgcm.org
> > > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > > 
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org 
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> 




More information about the MITgcm-devel mailing list