[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