[MITgcm-support] MITgcm-support Digest, Vol 126, Issue 43 (momentum budget)
Marco Reale
reale.marco82 at gmail.com
Sat Jan 4 11:16:17 EST 2014
Hi Jean-Michel,
You were right and I didn’t have updated the file time_step.F. I’ve run again the model and I got also the new diagnostics.The balance of U momentum works great: in the case of V the comparison between the curves (TOTVTEND and V balance works a bit worst (but not so bad).All my outputs for the balance comes from the model with a frequency in the data.diagnostics >0 . the only components that I compute by myself is the gradient of Etan(Rigid lid) that I compute on my mac using matlab (so not on my cluster) using the following formula :
-9.81*[(Etan(i,j)-Etan(i,j-1)]/DYC(i,j)
Any suggestion?
cheers
Marco
Il giorno 24/dic/2013, alle ore 15:09, 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. using RBCS to generate flow (katsman)
> 2. Re: Balance of momentum (Jean-Michel Campin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Dec 2013 13:54:37 +0100
> From: katsman <katsman at knmi.nl>
> To: <MITgcm-support at mitgcm.org>, Renske Gelderloos
> <Renske.Gelderloos at earth.ox.ac.uk>
> Subject: [MITgcm-support] using RBCS to generate flow
> Message-ID: <52B9840D.6060908 at knmi.nl>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> Dear MITgcm developers,
>
> Over the past years, I used the RBCS package to generate a flow in an
> (otherwise unforced) basin representing the Labrador Sea, by restoring
> the flow to a prescibed 3D-temperature and velocity field in a corner of
> the basin (T and velocity in geostrophic balance). This worked excellent
> in a (admittedly old) checkpoint58-version in which we manually added a
> restoring term on U and V analogous to the programmed T, S part.
>
> When I got a new workstation I thought it time to upgrade to the most
> recent MITgcm version, but I cannot get the package to work in the same
> way (and I tried many things over the past months, so I am getting a bit
> desperate...).
>
> The new checkpoint64 is supposed to be able to restore T,U and V, but I
> find that - when I prescribe my T,V fields again as before - in the
> sponge region defined by the mask, T is restored fine, while V is
> restored fine only during the first few timesteps of the simulation.
> Then a purely baroclinic U develops as well, while V becomes barotropic
> (despite RBCS acting on it). Intriguing, but not what I wanted.
>
> A test that really makes me think there is a bug in the rbcs package
> rather than me doing something stupid is that when I only restore T with
> a gradient in x, I expect to see a purely baroclinic V develop in
> geostrophic balance with that. In stead, nothing happens (I can run it
> for a month, no flow develops at all).
>
> One of the earlier versions (c62) has yet another version of the RBCS
> package. When I do a test with T-restore only (U,V is not standard in
> that one), a baroclinic flow does develop obeying geostrophy.
>
> Any ideas what is wrong here? I checked - the model does frequent the
> appropriate lines of code in rbcs_add_tendency in the c64 version to
> change the gV parameter - I suspect somewhere in the code U and V are
> mixed up. Notably, the baroclinic flow that develops in the sponge
> region is roughly the same strength as the V I prescribe
>
> Any ideas?? (if the description is unclear I can send pictures)
>
> Thanks in advance & happy holidays
> Caroline
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 24 Dec 2013 09:08:58 -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: <20131224140858.GA19034 at ocean.mit.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Marco,
>
> As mentionned earlier (message sent on Dec 10, see:
> http://mitgcm.org/pipermail/mitgcm-support/2013-December/008719.html ):
>> 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.
>
> so my question is which version of model/src/timestep.F are you using ?
> (the CVS revision number is found in the CVS Header line, generally the 1rst
> line of the file).
>
> Cheers,
> Jean-Michel
>
> On Tue, Dec 24, 2013 at 11:46:57AM +0100, Marco Reale wrote:
>> oundary="Apple-Mail=_53E7755B-E708-40DE-985D-93C38F267A87"
>>
>>
>> --Apple-Mail=_53E7755B-E708-40DE-985D-93C38F267A87
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>> charset=iso-8859-1
>>
>> Hi Jean-Michel,
>>
>> I downloaded the new version of MITGCM model and I ran it asking for AB_gU and AB_gV but during the run , regarding these diagnostics , I get from the model the following message (UAB and VAB are the output names that I have chosen for the output)
>>
>> - WARNING - from DIAGNOSTICS_OUT at iter= 360
>> - WARNING - diag.# 100 : AB_gU (# 1 ) in outp.Stream: UAB
>> - WARNING - has not been filled (ndiag= 0 )
>> WARNING DIAGNOSTICS_OUT => write ZEROS instead
>> - WARNING - from DIAGNOSTICS_OUT at iter= 360
>> - WARNING - diag.# 101 : AB_gV (# 1 ) in outp.Stream: VAB
>> - WARNING - has not been filled (ndiag= 0 )
>> WARNING DIAGNOSTICS_OUT => write ZEROS instead
>>
>>
>>
>> What does it mean this? It means that in my present configuration of the model AB_gU and AB_gV are not computed?
>>
>> cheers
>>
>> Marco
>>
>>
>>
>>
>> Il giorno 11/dic/2013, alle ore 17:09, 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. Re: MITgcm-support Digest, Vol 126, Issue 18 (momentum
>>> Budget) (Jean-Michel Campin)
>>> 2. discretization of curl: vorticity (Marco Reale)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 10 Dec 2013 17:47:17 -0500
>>> From: Jean-Michel Campin <jmc at ocean.mit.edu>
>>> To: mitgcm-support at mitgcm.org
>>> Subject: Re: [MITgcm-support] MITgcm-support Digest, Vol 126, Issue 18
>>> (momentum Budget)
>>> Message-ID: <20131210224717.GA4396 at ocean.mit.edu>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Wed, 11 Dec 2013 17:09:02 +0100
>>> From: Marco Reale <reale.marco82 at gmail.com>
>>> To: mitgcm-support at mitgcm.org
>>> Subject: [MITgcm-support] discretization of curl: vorticity
>>> Message-ID: <6C6B4D2E-FFA8-4790-9A0D-B0511DF63093 at gmail.com>
>>> Content-Type: text/plain; charset="windows-1252"
>>>
>>> Dear MITGCM users,
>>>
>>> first I want to thank Dave , Jean-Michel and Ryan for their help and useful suggestions in the previous post about momentum balance: averaging over many time steps gave me a good agreement between TOTUTEND/86400 and Um_Advec+Um_Diss+Um_dPHdx+dEta/dx+Um_ExternalForcings. Now I?m facing the question about the computation of vorticity balance. To compute vorticity I need to apply the curl to each member of momentum equation.
>>>
>>> My question is : Should I apply the curl in the form that is applied to U,V velocity fields as the model does to each member of Momentum budget (Um_Advec+Um_Diss+Um_dPHdx+dEta/dx+Um_ExternalForcings and Vm_Advec+Vm_Diss+Vm_dPHdx+dEta/dy+Vm_ExternalForcings) or there exists another to discretize the curl which might more suitable for this kind of computations (for example in the case of pressure terms)?I?ve already applied the model formula to my U,V output to compute Z3 and it works great.
>>>
>>> Looking forward to a response to my mail
>>>
>>> Cheers
>>>
>>> Marco
>>>
>>>
>>>
>>>
>>>
>>> ***********************************
>>> 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
>>>
>>> ***********************************
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131211/f48cdd64/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>>
>>> End of MITgcm-support Digest, Vol 126, Issue 25
>>> ***********************************************
>>
>> ***********************************
>> 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
>
>> e-Mail=_53E7755B-E708-40DE-985D-93C38F267A87--
>>
>>
>> --===============1883390550==
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Tr
>
>
>
>
> ------------------------------
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> End of MITgcm-support Digest, Vol 126, Issue 43
> ***********************************************
***********************************
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)
Società Italiana per le Scienze del Clima(SISC)
web-page: http://phdfluidmechanics.appspot.com/stud.html?Reale
skype: mcreal82
phone number: +39 3270888069
***********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140104/93501f25/attachment-0001.htm>
More information about the MITgcm-support
mailing list