[MITgcm-support] MITgcm-support Digest, Vol 126, Issue 18 (momentum Budget)

Jean-Michel Campin jmc at ocean.mit.edu
Tue Dec 10 17:47:17 EST 2013


Hi Marco,

There was a problem with the 2 diagnostics AB_gU and AB_gV (a typo in 
the routine that fills up these diags), so they were not filled at all.
This has been fixed yesterday (file model/src/timestep.F , CVS revision 1.55), 
so if you can update your code, it should fix it.

I (finally) applied this momentum budget check, over 1 time-step,
using a set-up similar to exp2, with/without Rigid-Lid, w/o staggerTimeStep, 
and w/o CD-Scheme, and it close up to machine precision: 
RMS of Total_gU ~ 10^-6 , RMS of residual ~ 10^-21.

Note that over 1 time-step, AB_gU & AB_gV were not always very small
(relative importance could be even larger without wind-stress),
and I would recommand to include them in your budget.
Also I was writing 64 bits output files (writeBinaryPrec=64).

Cheers,
Jean-Michel

On Sun, Dec 08, 2013 at 05:23:31PM +0100, Marco Reale wrote:
> Dear Jean-Michel, Ryan , Dave and Martin
> 
> First of all I want to thank all of  you  for your useful suggestions and advice. they improved a lot my analysis and so I want to thank you for this. I applied your suggestions in the analysis of momentum budget.Following Jean Michel my balance has been computed like 
> 
> TOTUTEND/86400=- gravity * ( ETAN(i) - ETAN(i-1) ) / DXC   + Um_dPHdx+ Um_Advec   + Um_Diss + Um_Ext (is zero in my case)+ AB_gU…I’m currently running again the model to get Adams-bahsfort momentum tendency(despite in the first steps these terms look to be zero).
> 
> I fixed a point at level iz=12 , i=9, j=22  and i checked the value of TOTUTEND/86400 and  Ubalance=- gravity * ( ETAN(i) - ETAN(i-1) ) / DXC   + Um_dPHdx+ Um_Advec   + Um_Diss + Um_Ext (is zero in my case) for some timesteps (t) :
> 
> 
> t=975
> TOTUTEND/86400=1.6289e-09
> Ubalance=1.4147e-09
> 
> t=1975
> 
> TOTUTEND/86400=1.5033e-09
> Ubalance= 1.5004e-09
> 
> t=1875
> TOTUTEND/86400=7.3823e-10
> Ubalance=8.4034e-10
> 
> 
> t=1775
> TOTUTEND/86400=-6.6106e-10
> Ubalance=-8.9608e-10
> 
> t=1990
> TOTUTEND/86400=1.9254e-09
> Ubalance=1.8055e-09
> 
> 
> t=2000
> TOTUTEND/86400=-2.0024e-09
> Ubalance=-1.5492e-09
> 
> So in some time steps the agreement between my estimation and model’s estimation is good , in other cases no.In your opinion should these values be ok?  Where might it be the problem? I add as attachment the file data* that I used in my simulation.Is there anything wrong?
> 
> Cheers
> Marco
> 
> 
> 
> Il giorno 07/dic/2013, alle ore 00:28, mitgcm-support-request at mitgcm.org ha scritto:
> 
> > Send MITgcm-support mailing list submissions to
> > 	mitgcm-support at mitgcm.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	http://mitgcm.org/mailman/listinfo/mitgcm-support
> > or, via email, send a message with subject or body 'help' to
> > 	mitgcm-support-request at mitgcm.org
> > 
> > You can reach the person managing the list at
> > 	mitgcm-support-owner at mitgcm.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of MITgcm-support digest..."
> > 
> > 
> > Today's Topics:
> > 
> >   1. Fwd:  input files for regional model (Jonny Williams)
> >   2. Surface Deep Convection Tutorial (Stroman, Ashley)
> >   3. Re: Balance of momentum (Jean-Michel Campin)
> >   4. Re: Balance of momentum (Ryan Abernathey)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Fri, 6 Dec 2013 17:32:30 +0000
> > From: Jonny Williams <Jonny.Williams at bristol.ac.uk>
> > To: "Menemenlis, Dimitris (3248)" <Dimitris.Menemenlis at jpl.nasa.gov>,
> > 	MITgcm Support <mitgcm-support at mitgcm.org>
> > Subject: [MITgcm-support] Fwd:  input files for regional model
> > Message-ID:
> > 	<CAA-NaP7e+icQAunLTH4k+apf50Rcgtx1WczSvex9Xe0t0WRQAQ at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> > 
> > Hello again
> > 
> > I think I'm now at the stage of starting to run the regional model for my
> > region of interest (as modified from the Arctic regional model)! Needless
> > to say that my first go has not worked so here is a brief run through of
> > what I've done so far to turn the Arctic regional model into my regional
> > model
> > 
> > (1)  Modified the 'data' file to reflect the cartesian coordinate system
> > now in use (copied from the 1D_ocean_ice_column verification experiment)...
> > 
> > # Gridding parameters
> > &PARM04
> > usingCartesianGrid=.TRUE.,
> > dXspacing=185.2.,
> > dYspacing=185.2.,
> > delZ   = 10.00, 10.00, 10.00, 10.00, 10.00, 10.00, 10.00, 10.01,
> > 10.03, 10.11, 10.32, 10.80, 11.76, 13.42, 16.04 , 19.82, 24.85,
> > 31.10, 38.42, 46.50, 55.00, 63.50, 71.58, 78.90, 85.15, 90.18,
> > 93.96, 96.58, 98.25, 99.25,100.01,101.33,104.56,111.33,122.83,
> > 139.09,158.94,180.83,203.55,226.50,249.50,272.50,295.50,318.50,
> > 341.50,364.50,387.50,410.50,433.50,456.50,
> > &
> > 
> > 
> > (2) Recompiled my executable (which worked) having already changed my
> > SIZE.h file to what I believe to be a correct set of processor
> > decomposition parameters
> > 
> > (3) Replaced all of the input '.dat' files with those which I have made
> > from the global forcing dataset which I am using and repaced the relevant
> > lines in, for example, data.exf and data.obcs.
> > 
> > This is basically the error I get (there is no extra information in the
> > STDERR and STDOUT files)
> > 
> > "PGFIO-F-233/namelist read/unit=11/too many constants to initialize group
> > item.
> > File name = scratch1.0012    formatted, sequential access   record = 52
> > *In source file exf_readparms.f, at line number 3657*
> > [NID 02232] 2013-12-06 17:09:30 Apid 6359875: initiated application
> > termination"
> > 
> > This refers to the following line...
> > 
> > "READ(  iUnit, nml = EXF_NML_04 )"
> > 
> > Which in turn refers to the following in data.exf...
> > 
> > "&EXF_NML_04
> > precip_lon0       = -30.0D0,
> > precip_lon_inc    = 0.1D0,
> > precip_lat0       = -70.0D0,
> > precip_lat_inc    = 800*0.1D0,
> > precip_nlon       = 451,
> > precip_nlat       = 801,"
> > 
> > I am trying to run at 0.1 degree resolution across a domain. Does this
> > error mean that I am trying to run at an impossibly high resolution for a
> > domain of this size?
> > 
> > Many thanks for any input once again and apologies for the long message.
> > 
> > Jonny
> > 
> > On 5 December 2013 18:32, Menemenlis, Dimitris (3248) <
> > Dimitris.Menemenlis at jpl.nasa.gov> wrote:
> > 
> >> For lat/lon gid, you don't need any grid information files.
> >> You specify everything in runtime parameter file "data"
> >> See, for example, MITgcm/verification/lab_sea/input/data
> >> 
> >>  &PARM04
> >> usingSphericalPolarGrid=.TRUE.,
> >> delX=20*2.E0,
> >> delY=16*2.E0,
> >> delZ= 10., 10., 15., 20., 20., 25., 35., 50., 75.,
> >>       100., 150., 200., 275., 350., 415., 450.,
> >>       500., 500., 500., 500., 500., 500., 500.,
> >> ygOrigin=46.,
> >> xgOrigin=280.,
> >> rSphere = 6371.D3,
> >> &
> >> 
> >>  On Dec 5, 2013, at 10:24 AM, Jonny Williams wrote:
> >> 
> >> Hi there
> >> 
> >> I'm attempting to modify the Arctic regional model described here...
> >> 
> >> http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/arctic/cs_36km/readme.txt
> >> http://ecco2.jpl.nasa.gov/data1/arctic/run_template2/README_arctic2.txt
> >> 
> >> My question is regarding the coordinate system. The Arctic model uses
> >> "usingCurvilinearGrid=.TRUE.," in the data input file but I want to use a
> >> regular latitude-longitude grid ("usingCartesianGrid=.TRUE.").
> >> 
> >> When I do this, do I also need all of the many other input files needed
> >> (LATC.bin, LONC.bin, RA.bin, RAW.bin etc etc)?
> >> 
> >> If I don't need these files, then whereabouts do I specify information
> >> regarding the grid system?
> >> 
> >> Many thanks :)
> >> 
> >> Jonny
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >> 
> >> 
> > 
> > 
> > -- 
> > Dr Jonny Williams
> > School of Geographical Sciences
> > University of Bristol
> > University Road
> > BS8 1SS
> > 
> > +44 (0)117 3318352
> > jonny.williams at bristol.ac.uk
> > bit.ly/jonnywilliams
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131206/ef47b9a6/attachment-0001.htm>
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Fri, 6 Dec 2013 22:22:09 +0000
> > From: "Stroman, Ashley" <acs08g at my.fsu.edu>
> > To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> > Subject: [MITgcm-support] Surface Deep Convection Tutorial
> > Message-ID: <956C014B-2765-4A37-9CB8-BCD11A1A2A8D at my.fsu.edu>
> > Content-Type: text/plain; charset="Windows-1252"
> > 
> > Hello.
> > 
> > I am trying to run the gendata script within the surface deep convection tutorial and I have two questions.
> > 
> > 1.) When I run the script in Matlab, I get an error output that says
> > 
> > BLAS loading error:
> > mkl.so: failed to map segment from shared object: Cannot allocate
> > memory
> > 
> > Error in gendata (line 41)
> > xc=x'*ones(1,ny); yc=ones(nx,1)*y;
> > 
> > Is there a way to rewrite this part of the code so it won?t crash on me?
> > 
> > 2.) In the script, what is var calculating, and what what does the [1:1000) and /1000 come from?
> > 
> > Thanks.
> > 
> > Best,
> > Ashley Stroman
> > 
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Fri, 6 Dec 2013 17:48:15 -0500
> > From: Jean-Michel Campin <jmc at ocean.mit.edu>
> > To: mitgcm-support at mitgcm.org
> > Subject: Re: [MITgcm-support] Balance of momentum
> > Message-ID: <20131206224815.GA21051 at ocean.mit.edu>
> > Content-Type: text/plain; charset=utf-8
> > 
> > Hi Marco, Dave, Martin and Ryan,
> > 
> > I would like to clarify few things regarding diagnostics of the
> > horizontal momentum equation. I did not find very easy to follow
> > the discussion started ~ a week ago (the subject has changed, not 
> > always easy to distinguish quickly the answer from the quoting of 
> > the original message and long lines are not easy to read from the 
> > mitgcm-support archive web-site). But I hope this will not add more
> > confusion.
> > 
> > The different horizontal momentum terms are split into different
> > diagnostics, mainly to reflect the time-stepping options (forward
> > in time = explicit / backward in time = implicit, and going
> > through the Adams-Bashforth or not). A finer decomposition can
> > be obtained with a 2nd (larger) set of diagnostics that are specific
> > to the formulation used (flux-form or vector-invariant).
> > 
> > 1) the surface pressure horizontal gradient needs to be added.
> > this was mentioned in the Emily's message that Martin (on Nov 28) pointed to:
> > http://mitgcm.org/pipermail/mitgcm-support/2010-December/006921.html
> > and it's needed whether or not the free-surface or the rigid-lid is used
> > (in this later case, this is the pressure from the lid).
> > 
> > To Ryan: Having many diagnostics slows down the code (it's not 
> > clear how much, but it does) and when some term can be easily and
> > precisely recomputed from other diags, it's a matter of choice
> > if we decide to add a diagnostics or not. 
> > In this case, from a single 2-D diagnostics output (ETAN), one can 
> > compute the horizontal gradient in both direction (DXC & DYC are 
> > standard grid output); but we would need two 3-D diagnostics (to get it 
> > properly masked) for the contribution at each level of the du/dt 
> > and dv/dt equations. So, it's not very clear to me that these two
> > 3-D diagnostics should be added (may be we can continue this discussion
> > elsewhere). 
> > 
> > 2) Diagnostics Um_Advec and Um_Advec already contain the Coriolis
> > term, unless one uses the CD-Scheme (and in this case, 
> > Um_Cori and Vm_Cori needs to be added). 
> > The main reason for this is that when using the vector-invariant form, 
> > Coriolis term can be incorporated to the absolute vorticity (and then 
> > treated with the advection), and in order to make the diagnostics more 
> > similar between the 2 momentum formulations, the same convention was 
> > retained also for the flux-form.
> > Note that, for the same reasons, the metrics-terms are also part
> > of Um_Advec and Um_Advec.
> > 
> > Now, here is where I get confused: In Emily's message, the CD-Scheme is 
> > not used, but momentum budget is closed by adding Um_Cori to to Um_Advec ?
> > 
> > 3) Diagnostics Um_Diss and Vm_Diss contain all the explicit (forward
> > in time) dissipation terms (horizontal viscosity, explicit vertical
> > viscosity, side drag, bottom friction).
> > If one uses implicit vertical viscosity (implicitViscosity=.TRUE.,),
> > the vertical viscosity tendency needs to be added (as explained in
> > Emily's message).
> > 
> > 4) forcing (diagnostics Um_Ext, Vm_Ext) and baroclinic pressure gradient
> > (diagnostics Um_dPHdx and Vm_dPHdy) needs to be added separately.
> > If filters are used (Shapiro, FFT), their contribution needs to be
> > diagnosed separately (e.g., using SHAP_dU and SHAP_dV ).
> > 
> > 5) The Adams-Bashforth will alter the momentum budget (although over
> > a long period, most cancel in time-averaging) and, depending on the 
> > particular set of parameter (e.g., staggerTimeStep, forcing_In_AB, 
> > momDissip_In_AB ) it's not always negligible. This AB effect can
> > be diagnosed using the 2 diagnostics AB_gU and AB_gV (added 2 years ago).
> > 
> > So that the momentum budget for the U componentic can be diagnosed with:
> > 
> > [du/dt] = - gravity * ( ETAN(i) - ETAN(i-1) ) / DXC
> >        + Um_dPHdx
> >        + Um_Advec   (+ Um_Cori : but only if using CD-Scheme )
> >        + Um_Diss    (+ Implicit vertical viscosity tendency)
> >        + Um_Ext
> >        + AB_gU
> > 
> > Some remarks:
> > a) When using the flux-form formulation, the non-linear free-surface can introduce 
> >   a small difference (rescaling) which is not currently diagnosed.
> > b) the 3-D Coriolis ( in 2 Omega cos(Phi) between U and W) is not currently
> >  diagnosed separately (and is not part of Um_Cori) but is part of
> >  Um_Advec. Also using the quasiHydrostatic option might alter some of the 
> >  diagnostics (e.g., what is described as the hydrostatic pressure is no 
> >  longer strictly hydrostatic).
> > c) when trying to do a budget over just 1 time-step, one needs to be aware 
> >  of the precise time-discretisation of the the first term which is evaluated 
> >  in the model as 
> >   - gravity * {  implicSurfPress * (d.EtaN/dx)^n+1 
> >                +(1-implicSurfPress)*(d.EtaN/dx)^n }
> >  (using the default implicSurfPress=1 , it might be be easier to use 
> >   snap-shot output Eta.[iter+1] to get EtaN^n+1 )
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Thu, Dec 05, 2013 at 10:23:04AM +0000, David Munday wrote:
> >> Hi Marco,
> >> 
> >> Um_HydroP isn't in my available_diagnostics, I can't find it anywhere in the documentation, and grepping the code turns up nothing. Is it the same as Um_dPHdx?
> >> 
> >> In general, I'd expect Um_Advec and Um_dPHdx to be similar in magnitude and of opposite sign, due to the dominance of geostrophic balance. Assuming Um_HydroP is Um_dPHdx by another name, then its magnitude is about right, but its sign is wrong (or Um_Advec's is). Taking the difference and adding Um_Diss gives me -4.3197E-9, so you're still missing a term.
> >> 
> >> Have you output every single Um_* diagnostic available, including the ones you think are zero, the implicit/explicit viscosity, and the gradient in SSH?
> >> 
> >> Best wishes,
> >> 
> >> Dave
> >> 
> >> 
> >> On 4 Dec 2013, at 21:44, Marco Reale wrote:
> >> 
> >> Hi David,
> >> 
> >> and thanks a lot for your response: I followed your suggestion.
> >> 
> >> So finally  the equation will be :
> >> 
> >> TOTUTEND/86400=Um_Advec+Um_diss+Um_HydroP;
> >> 
> >> each of these members of the equation are 4D arrays : following a point to check the balance at t = 30, level=12, i=9, j=30 and I got the following results:
> >> 
> >> TOTUTEND/86400= -8.0561e-10
> >> Um_Advec= 2.5398e-07
> >> Um_diss= 7.7003e-09
> >> Um_HydroP=2.4196e-07
> >> 
> >> the balance of this term is 5.0365e-07
> >> 
> >> 
> >> So I have done something wrong: I?m working with rough data without taking into account volume of cells, etc.
> >> 
> >> Any suggestions?
> >> 
> >> Marco
> >> 
> >> 
> > 
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-support
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 4
> > Date: Fri, 6 Dec 2013 18:28:15 -0500
> > From: Ryan Abernathey <ryan.abernathey at gmail.com>
> > To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> > Subject: Re: [MITgcm-support] Balance of momentum
> > Message-ID: <A4DDE4B5-8675-4547-9833-241637BD01AC at gmail.com>
> > Content-Type: text/plain;	charset=utf-8
> > 
> > JMC,
> > What you say about the etan diagnostics makes perfect sense. I misunderstood the earlier email and thought there was some missing term that could only be output through hacking the code. I never had to do this in my momentum budgets, so I was kind of confused / worried. 
> > -Ryan
> > 
> > Sent from my iPhone
> > 
> > On Dec 6, 2013, at 5:48 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> > 
> >> Hi Marco, Dave, Martin and Ryan,
> >> 
> >> I would like to clarify few things regarding diagnostics of the
> >> horizontal momentum equation. I did not find very easy to follow
> >> the discussion started ~ a week ago (the subject has changed, not 
> >> always easy to distinguish quickly the answer from the quoting of 
> >> the original message and long lines are not easy to read from the 
> >> mitgcm-support archive web-site). But I hope this will not add more
> >> confusion.
> >> 
> >> The different horizontal momentum terms are split into different
> >> diagnostics, mainly to reflect the time-stepping options (forward
> >> in time = explicit / backward in time = implicit, and going
> >> through the Adams-Bashforth or not). A finer decomposition can
> >> be obtained with a 2nd (larger) set of diagnostics that are specific
> >> to the formulation used (flux-form or vector-invariant).
> >> 
> >> 1) the surface pressure horizontal gradient needs to be added.
> >> this was mentioned in the Emily's message that Martin (on Nov 28) pointed to:
> >> http://mitgcm.org/pipermail/mitgcm-support/2010-December/006921.html
> >> and it's needed whether or not the free-surface or the rigid-lid is used
> >> (in this later case, this is the pressure from the lid).
> >> 
> >> To Ryan: Having many diagnostics slows down the code (it's not 
> >> clear how much, but it does) and when some term can be easily and
> >> precisely recomputed from other diags, it's a matter of choice
> >> if we decide to add a diagnostics or not. 
> >> In this case, from a single 2-D diagnostics output (ETAN), one can 
> >> compute the horizontal gradient in both direction (DXC & DYC are 
> >> standard grid output); but we would need two 3-D diagnostics (to get it 
> >> properly masked) for the contribution at each level of the du/dt 
> >> and dv/dt equations. So, it's not very clear to me that these two
> >> 3-D diagnostics should be added (may be we can continue this discussion
> >> elsewhere). 
> >> 
> >> 2) Diagnostics Um_Advec and Um_Advec already contain the Coriolis
> >> term, unless one uses the CD-Scheme (and in this case, 
> >> Um_Cori and Vm_Cori needs to be added). 
> >> The main reason for this is that when using the vector-invariant form, 
> >> Coriolis term can be incorporated to the absolute vorticity (and then 
> >> treated with the advection), and in order to make the diagnostics more 
> >> similar between the 2 momentum formulations, the same convention was 
> >> retained also for the flux-form.
> >> Note that, for the same reasons, the metrics-terms are also part
> >> of Um_Advec and Um_Advec.
> >> 
> >> Now, here is where I get confused: In Emily's message, the CD-Scheme is 
> >> not used, but momentum budget is closed by adding Um_Cori to to Um_Advec ?
> >> 
> >> 3) Diagnostics Um_Diss and Vm_Diss contain all the explicit (forward
> >> in time) dissipation terms (horizontal viscosity, explicit vertical
> >> viscosity, side drag, bottom friction).
> >> If one uses implicit vertical viscosity (implicitViscosity=.TRUE.,),
> >> the vertical viscosity tendency needs to be added (as explained in
> >> Emily's message).
> >> 
> >> 4) forcing (diagnostics Um_Ext, Vm_Ext) and baroclinic pressure gradient
> >> (diagnostics Um_dPHdx and Vm_dPHdy) needs to be added separately.
> >> If filters are used (Shapiro, FFT), their contribution needs to be
> >> diagnosed separately (e.g., using SHAP_dU and SHAP_dV ).
> >> 
> >> 5) The Adams-Bashforth will alter the momentum budget (although over
> >> a long period, most cancel in time-averaging) and, depending on the 
> >> particular set of parameter (e.g., staggerTimeStep, forcing_In_AB, 
> >> momDissip_In_AB ) it's not always negligible. This AB effect can
> >> be diagnosed using the 2 diagnostics AB_gU and AB_gV (added 2 years ago).
> >> 
> >> So that the momentum budget for the U componentic can be diagnosed with:
> >> 
> >> [du/dt] = - gravity * ( ETAN(i) - ETAN(i-1) ) / DXC
> >>       + Um_dPHdx
> >>       + Um_Advec   (+ Um_Cori : but only if using CD-Scheme )
> >>       + Um_Diss    (+ Implicit vertical viscosity tendency)
> >>       + Um_Ext
> >>       + AB_gU
> >> 
> >> Some remarks:
> >> a) When using the flux-form formulation, the non-linear free-surface can introduce 
> >>  a small difference (rescaling) which is not currently diagnosed.
> >> b) the 3-D Coriolis ( in 2 Omega cos(Phi) between U and W) is not currently
> >> diagnosed separately (and is not part of Um_Cori) but is part of
> >> Um_Advec. Also using the quasiHydrostatic option might alter some of the 
> >> diagnostics (e.g., what is described as the hydrostatic pressure is no 
> >> longer strictly hydrostatic).
> >> c) when trying to do a budget over just 1 time-step, one needs to be aware 
> >> of the precise time-discretisation of the the first term which is evaluated 
> >> in the model as 
> >>  - gravity * {  implicSurfPress * (d.EtaN/dx)^n+1 
> >>               +(1-implicSurfPress)*(d.EtaN/dx)^n }
> >> (using the default implicSurfPress=1 , it might be be easier to use 
> >>  snap-shot output Eta.[iter+1] to get EtaN^n+1 )
> >> 
> >> Cheers,
> >> Jean-Michel
> >> 
> >> On Thu, Dec 05, 2013 at 10:23:04AM +0000, David Munday wrote:
> >>> Hi Marco,
> >>> 
> >>> Um_HydroP isn't in my available_diagnostics, I can't find it anywhere in the documentation, and grepping the code turns up nothing. Is it the same as Um_dPHdx?
> >>> 
> >>> In general, I'd expect Um_Advec and Um_dPHdx to be similar in magnitude and of opposite sign, due to the dominance of geostrophic balance. Assuming Um_HydroP is Um_dPHdx by another name, then its magnitude is about right, but its sign is wrong (or Um_Advec's is). Taking the difference and adding Um_Diss gives me -4.3197E-9, so you're still missing a term.
> >>> 
> >>> Have you output every single Um_* diagnostic available, including the ones you think are zero, the implicit/explicit viscosity, and the gradient in SSH?
> >>> 
> >>> Best wishes,
> >>> 
> >>> Dave
> >>> 
> >>> 
> >>> On 4 Dec 2013, at 21:44, Marco Reale wrote:
> >>> 
> >>> Hi David,
> >>> 
> >>> and thanks a lot for your response: I followed your suggestion.
> >>> 
> >>> So finally  the equation will be :
> >>> 
> >>> TOTUTEND/86400=Um_Advec+Um_diss+Um_HydroP;
> >>> 
> >>> each of these members of the equation are 4D arrays : following a point to check the balance at t = 30, level=12, i=9, j=30 and I got the following results:
> >>> 
> >>> TOTUTEND/86400= -8.0561e-10
> >>> Um_Advec= 2.5398e-07
> >>> Um_diss= 7.7003e-09
> >>> Um_HydroP=2.4196e-07
> >>> 
> >>> the balance of this term is 5.0365e-07
> >>> 
> >>> 
> >>> So I have done something wrong: I?m working with rough data without taking into account volume of cells, etc.
> >>> 
> >>> Any suggestions?
> >>> 
> >>> Marco
> >> 
> >>> _______________________________________________
> >>> MITgcm-support mailing list
> >>> MITgcm-support at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-support
> > 
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
> > 
> > 
> > End of MITgcm-support Digest, Vol 126, Issue 18
> > ***********************************************
> 
> ***********************************
> Marco Reale
> ph.D student "Environmental and Industrial Fluid Mechanics"-XXVII cycle
> University of Trieste-Department of Mathematics and Informatics
> National Institute of Geophysics and Oceanography (OGS)
> International Center for Theorethical Physics (ICTP)
> Italian Geophysical Association (AGI)
> Italian Meteorological Society (SMI)
> European Geophysical Union (EGU)
> web-page: http://phdfluidmechanics.appspot.com/stud.html?Reale
> skype: mcreal82
> phone number: +39 3270888069
> 
> ***********************************
> 

> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list