[MITgcm-support] Effect of 'vectorInvariantMomentum' flag on first order circulation
Jean-Michel Campin
jmc at mit.edu
Tue Mar 28 13:55:18 EDT 2017
Hi Dhruv and other,
I did few more tests with this zonally re-entrant channel set-up (with a bump
in the middle):
1) The unrealistic large velocity near the bump is also developing when I use:
vectorInvariantMomentum=T and selectVortScheme=0 (useJamartWetPoints=F)
whether I use highOrderVorticity or not.
The thing I forgot is that, by default, highOrderVorticity uses selectVortScheme=0
but with highOrderVorticity=F, the default is to use selectVortScheme=1
(a modified version of selectVortScheme=0 scheme that I put a long time
ago to fix some recip_hFacZ effects near mountains in, at the time, some
atmospheric set-up).
The problem is not strictly due to masking but rather due to partial-cell factor
(in this channel set-up, recip_hFac is larger than 6 in few places) in relative
vorticity advection term but not accounted for in coriolis term (mom_vi_coriolis.F)
unless useJamartWetPoints=T. Vertical advection of momentum might also contribute.
The problem does not show up when I use:
selectVortScheme=2 (highOrderVorticity=T or F) or selectVortScheme=3 ;
or useAbsVorticity=T (with any selectVortScheme option) and highOrderVorticity=F
or useAbsVorticity=T and highOrderVorticity=T (with selectVortScheme=0 or 2)
2) It's not clear to me how this set-up is going to maintain the stratification
and it makes it more difficult to evaluate the solution with the different options
listed above (except in the few "wrong" cases with unrealistic velocity).
For instance, some options produce a more noisy solution that results in
a faster erosion of initial stratification.
In this set-up, the combination of
useAbsVorticity=T with selectVortScheme=3 (and highOrderVorticity=F)
seems to works nicely, not noisy solution that also looks like the flux-form one.
But other combinations might work as well.
3) regarding highOrderVorticity=T option:
It's supposed to provide a 4th order in space discretisation of horizontal
advection of vorticity, under the assumptions:
in mom_vi_u_coriolis_c4.F : uniform vVel in Y direction ;
in mom_vi_v_coriolis_c4.F : uniform uVel in X direction ;
probably also requires a uniform hFac field.
But I suspect that the 1/12 factor should be replaced by a 1/6 factor to
make it a 4th order scheme (under the above assumptions).
Cheers,
Jean-Michel
On Wed, Mar 08, 2017 at 08:36:39PM -0500, Dhruv Balwada wrote:
> Hi Jean-Michel and everyone,
>
> Thanks a lot for getting to the heart of the problem. I am glad that
> choosing that right combinations flags leads to the appropriate answers. I
> hope this point (I am sure there are other similar ones) can be
> highlighted/noted somewhere on the MITgcm manual.
>
> One point I want to mention is that I changed the flags for my run based on
> the llc simulations. Here is their data file
> http://wwwcvs.mitgcm.org/viewvc/MITgcm/MITgcm_contrib/llc_hires/llc_4320/input/data?revision=1.14&view=markup
>
>
> I am wondering if their solutions are being effected by this problem? They
> don't have the useJamartWetPoints=.TRUE., set.
>
> Best,
> Dhruv
>
>
>
> On Wed, Mar 8, 2017 at 7:46 PM, Jean-Michel Campin <jmc at mit.edu> wrote:
>
> > Hi Dave & Andrea,
> >
> > I did a quick test running Dhruv's set-up with:
> > vectorInvariantMomentum=.TRUE.,
> > highOrderVorticity=.TRUE.,
> > useJamartWetPoints=.TRUE.,
> > and it looks fine, does not develop the "strange" velocity field.
> >
> > Cheers,
> > Jean-Michel
> >
> > On Wed, Mar 08, 2017 at 08:48:48AM +0000, Munday, Dave wrote:
> > > I've been using useJamartWetPoints too, which I found helps with the
> > noisy vertical velocity. Although I never saw the extreme problems with
> > Coriolis seen in Jamart & Ozer.
> > >
> > > I???ve also been using useJamartMomAdv. Although looking at the code it
> > looks like this one doesn???t do anything with highOrderViscosity.
> > >
> > > D
> > >
> > > > On 8 Mar 2017, at 19:01, Andrea Cimatoribus <
> > andrea.cimatoribus at epfl.ch> wrote:
> > > >
> > > > I have also been using:
> > > > vectorInvariantMomentum=.TRUE.,
> > > > highOrderVorticity=.TRUE.,
> > > > to reduce noise similarly to DM, and never noticed any issue, with
> > model comparing generally very well to observations (however, my setup is
> > completely different from the ACC case). I was wondering if the option:
> > > > usejamartwetpoints=.TRUE.,
> > > > may change (fix?) the results you are having. I remember there was a
> > reason why I set this to true but, embarrassingly, I cannot recall it now.
> > > > Best,
> > > > Andrea
> > > >
> > > > Andrea Cimatoribus
> > > > postdoctoral researcher
> > > > EPFL ENAC IIE ECOL
> > > > https://people.epfl.ch/andrea.cimatoribus
> > > >
> > > > On 07/03/17 22:54, Jean-Michel Campin wrote:
> > > >> i Dhruv,
> > > >>
> > > >> An update on your set-up behavior:
> > > >> 1) I think I was able to reproduce the problem, running the 2 cases
> > > >> (vectorInvariantMomentum =T vs =F) for 1 yr each, labeled 'v01' and
> > 'f01' respectively.
> > > >> 2) I also run the vectorInvariantMomentum=T case (label='v02') for
> > just 6 months,
> > > >> starting from pickup from the other run (vectorInvariantMomentum=F)
> > at t=6.month.
> > > >> This was useful because the flow is already eddying (@ t= 6.month)
> > > >> but the model also switch to this "strange" behavior after less than
> > 1 month.
> > > >> 3) The only test I did afterward (v03) was like previous test (2) but
> > commenting out:
> > > >> highOrderVorticity=.TRUE.,
> > > >> I've attached a plot of KE evolution from the monitor output.
> > > >>
> > > >> I have the impression that the reason of this strange behavior is a
> > bad boundary
> > > >> conditions (i.e., wrong land/ocean masking or some missing partial
> > cell factor in
> > > >> pkg/mom_vecinv/mom_vi_v_coriolis_c4.F) in the 4th Order
> > discretization
> > > >> of (in this case, relative) vorticity that positively feeds back
> > > >> on the flow field to generate very strong meridional currents
> > (northward east
> > > >> of the ridge and southward west of the ridge), much larger (> 4.m/s)
> > than anywhere
> > > >> else in the domain, at least early on. This can clearly be seen on
> > V.component plot
> > > >> at t=7.month in my experiment "v02", starting to develop along the
> > northern part
> > > >> of the ridge just above the bottom cell rows (2nd wet cell above the
> > bottom).
> > > >>
> > > >> Will need to figure out how this positive feedback works (I
> > personally rarely
> > > >> use this option highOrderVorticity=T) ; also, little bit surprised
> > that the
> > > >> model did not blow up, but few factors -- bottom drag + KPP +
> > horizontal
> > > >> viscC4leith with large viscA4GridMax -- might help to stabilize ?
> > > >>
> > > >> One last thing: highOrderVorticity is specific to pkg/mom_vecinv;
> > > >> there is no equivalent in pkg/mom_fluxform (only centered 2nd Order
> > > >> advection scheme there) and setting highOrderVorticity=T has no effect
> > > >> when vectorInvariantMomentum=F.
> > > >> I would expect smaller differences, in the interior, between the 2
> > mom pkgs
> > > >> when highOrderVorticity is not used (especially given the masking
> > problem !)
> > > >> and
> > > >> 1) vectorInvariantMomentum=T
> > > >> with useAbsVorticity=T
> > > >> and selectVortScheme=2
> > > >> is compared to:
> > > >> 2) vectorInvariantMomentum=F
> > > >> with useEnergyConservingCoriolis=T
> > > >>
> > > >> Cheers,
> > > >> Jean-Michel
> > > >>
> > > >> On Fri, Mar 03, 2017 at 12:34:35AM -0500, Dhruv Balwada wrote:
> > > >>> Hi Bruno,
> > > >>>
> > > >>> Removing the topography made the solutions for the two cases be the
> > same.
> > > >>> This is crazy interesting, I think I need to understand your paper
> > better.
> > > >>>
> > > >>> Best,
> > > >>> Dhruv
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Thu, Mar 2, 2017 at 2:09 PM, Dhruv Balwada <db194 at nyu.edu> wrote:
> > > >>>
> > > >>>> Hi Bruno,
> > > >>>>
> > > >>>> I haven't removed the topography. I will set that up now. I did try
> > to do
> > > >>>> the run with no-slip and free-slip walls. The solution was the same
> > in
> > > >>>> both.
> > > >>>>
> > > >>>> Best,
> > > >>>> Dhruv
> > > >>>>
> > > >>>> On Thu, Mar 2, 2017 at 2:08 PM, Dhruv Balwada <db194 at nyu.edu>
> > wrote:
> > > >>>>
> > > >>>>> Hi Jean-Michel,
> > > >>>>>
> > > >>>>> The experiment setup is now available at -
> > https://github.com/dhruvbalw
> > > >>>>> ada/channel_run_20km
> > > >>>>>
> > > >>>>> I am using a version of the MITgcm that I downloaded in the
> > beginning of
> > > >>>>> February.
> > > >>>>>
> > > >>>>> The difference between two runs appears in a matter of 1 year of
> > the run.
> > > >>>>> I would probably run it for 2-3 years to see it clearly. On the
> > computers
> > > >>>>> here with 25 cores it took about 1 hour to run. So, its very fast.
> > > >>>>>
> > > >>>>> Let me know if you need any other files, and I can add them to the
> > git
> > > >>>>> directory.
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> Dhruv
> > > >>>>>
> > > >>>>> On Thu, Mar 2, 2017 at 10:37 AM, Jean-Michel Campin <jmc at mit.edu>
> > wrote:
> > > >>>>>
> > > >>>>>> Hi Dhruv,
> > > >>>>>>
> > > >>>>>> OK, this is a good start.
> > > >>>>>> Could you provide me (off the list since there is some strict
> > size limit
> > > >>>>>> there)
> > > >>>>>> a complete copy of the set up, including the customized/modified
> > "code"
> > > >>>>>> directory,
> > > >>>>>> the input parameter files ( data*, eedata) and the binary input
> > files
> > > >>>>>> needed
> > > >>>>>> to run the set-up.
> > > >>>>>> Also, if you are not using the latest MITgcm code, which version
> > is it ?
> > > >>>>>>
> > > >>>>>> And finally, how long would I need to run it to see some
> > significant
> > > >>>>>> differences
> > > >>>>>> (this was part of my earlier email, but not clearly expressed).
> > > >>>>>> May be a pickup file could allow to reduce the length of these
> > tests ?
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>> Jean-Michel
> > > >>>>>>
> > > >>>>>> On Wed, Mar 01, 2017 at 05:47:25PM -0500, Dhruv Balwada wrote:
> > > >>>>>>> Hi Jean-Michel,
> > > >>>>>>>
> > > >>>>>>> I tried the test you suggested by turning off all optimization,
> > and
> > > >>>>>> nothing
> > > >>>>>>> changed. Here are the outputs in prints of python notebooks. I
> > have
> > > >>>>>> also
> > > >>>>>>> attached the opt and data file. The data file for both runs
> > point to
> > > >>>>>> the
> > > >>>>>>> exact same forcing files on the hard drive.
> > > >>>>>>>
> > > >>>>>>> Best,
> > > >>>>>>> Dhruv
> > > >>>>>>>
> > > >>>>>>> On Tue, Feb 28, 2017 at 10:27 AM, Dhruv Balwada <db194 at nyu.edu>
> > wrote:
> > > >>>>>>>
> > > >>>>>>>> Hello everyone,
> > > >>>>>>>>
> > > >>>>>>>> Thanks for the quick responses.
> > > >>>>>>>>
> > > >>>>>>>> @ Jean-Michel I will follow your suggestions and report back on
> > them
> > > >>>>>> soon.
> > > >>>>>>>>
> > > >>>>>>>> Best,
> > > >>>>>>>> Dhruv
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Mon, Feb 27, 2017 at 3:56 PM, Jean-Michel Campin <
> > jmc at mit.edu>
> > > >>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Hi Dhruv,
> > > >>>>>>>>>
> > > >>>>>>>>> It's a strange results. Both pkgs (mom_fluxform and mom_vecinv)
> > > >>>>>> have been
> > > >>>>>>>>> tested and used in many different configs, and no significant
> > recent
> > > >>>>>>>>> changes
> > > >>>>>>>>> that would be suspicious.
> > > >>>>>>>>>
> > > >>>>>>>>> I suggest to try to work on a short test run:
> > > >>>>>>>>> 1) long enough to detect some significant differences between
> > the 2
> > > >>>>>> cases:
> > > >>>>>>>>> vectorInvariantMomentum=T and = F
> > > >>>>>>>>> 2) short enough so that the same 2 runs could be repeated with
> > zero
> > > >>>>>>>>> compiler
> > > >>>>>>>>> optimization (-ieee or -devel with many standard optfile).
> > > >>>>>>>>> And from there, we could work on trying to reproduce the
> > problem on
> > > >>>>>>>>> different machine/compiler ... etc.
> > > >>>>>>>>> Once we are able to reproduce the problem, should not take too
> > long
> > > >>>>>> to
> > > >>>>>>>>> fix.
> > > >>>>>>>>>
> > > >>>>>>>>> Cheers,
> > > >>>>>>>>> Jean-Michel
> > > >>>>>>>>>
> > > >>>>>>>>> On Thu, Feb 23, 2017 at 02:58:53PM -0500, Dhruv Balwada wrote:
> > > >>>>>>>>>> Hi MITgcm community,
> > > >>>>>>>>>>
> > > >>>>>>>>>> I have recently been stumped an issue with the MITgcm
> > > >>>>>>>>> vectorInvariantMomentum
> > > >>>>>>>>>> flag.
> > > >>>>>>>>>>
> > > >>>>>>>>>> **The model setup** is meant to be an ideal representation of
> > the
> > > >>>>>> ACC
> > > >>>>>>>>>> (following Abernathey and Cessi 2014). It has the following
> > > >>>>>> components -
> > > >>>>>>>>>> a) Linear temperature relaxation at the surface
> > > >>>>>>>>>> b) Zonal wind with sinusoidal structure
> > > >>>>>>>>>> c) Initial temp field is zonally symmetric and the thermocline
> > > >>>>>> shoals
> > > >>>>>>>>> from
> > > >>>>>>>>>> north to south (similar to the ACC).
> > > >>>>>>>>>> d) Resolution is 20km, and domain size is 2000km * 2000km.
> > > >>>>>>>>>> e) Zonally periodic and meridional walls
> > > >>>>>>>>>> f) A zonal gaussian bump is the topographic feature, which is
> > > >>>>>>>>> meridionaly
> > > >>>>>>>>>> independent.
> > > >>>>>>>>>>
> > > >>>>>>>>>> **The issue** I am facing is that the circulation pattern
> > > >>>>>> completely
> > > >>>>>>>>>> changes when I change the "vectorInvariantMomentum" flag.
> > > >>>>>>>>>> When the flag is set to false (default), the model recreates
> > an
> > > >>>>>> ACC like
> > > >>>>>>>>>> flow. Flow is from west to east and strongly perturbed by the
> > > >>>>>> presence
> > > >>>>>>>>> of
> > > >>>>>>>>>> topography.
> > > >>>>>>>>>> When the flag is set to true (default), the model does
> > something
> > > >>>>>> else.
> > > >>>>>>>>> Flow
> > > >>>>>>>>>> is from east to west, with a strong boundary flow from the
> > west
> > > >>>>>> to east
> > > >>>>>>>>>> near the southern boundary.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Any help would be appreciated.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I have posted some visualizations and data file here -
> > > >>>>>>>>>> https://sites.google.com/site/dhruvbalwada/blog/mitgcmissuew
> > > >>>>>>>>> ithvectorinvariantmomentumflag
> > > >>>>>>>>>>
> > > >>>>>>>>>> Here is the data file (obviously the vectorinvariantmomentum
> > flag
> > > >>>>>> is
> > > >>>>>>>>>> changed between two runs.
> > > >>>>>>>>>>
> > > >>>>>>>>>> &PARM01
> > > >>>>>>>>>>
> > > >>>>>>>>>> # viscosity
> > > >>>>>>>>>>
> > > >>>>>>>>>> viscAr=5.6614E-04,
> > > >>>>>>>>>>
> > > >>>>>>>>>> viscC4Leith=2.15,
> > > >>>>>>>>>>
> > > >>>>>>>>>> viscC4Leithd=2.15,
> > > >>>>>>>>>>
> > > >>>>>>>>>> viscA4GridMax=0.8,
> > > >>>>>>>>>>
> > > >>>>>>>>>> useAreaViscLength=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> highOrderVorticity=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # diffusivity
> > > >>>>>>>>>>
> > > >>>>>>>>>> tempAdvScheme=7,
> > > >>>>>>>>>>
> > > >>>>>>>>>> diffKrT=5.44e-7,
> > > >>>>>>>>>>
> > > >>>>>>>>>> saltStepping=.FALSE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> staggerTimeStep=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # multiDimAdvection=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> vectorInvariantMomentum=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # initial vertical profiles of T and S
> > > >>>>>>>>>>
> > > >>>>>>>>>> sRef=30*35.0000,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # equation of state
> > > >>>>>>>>>>
> > > >>>>>>>>>> eosType='LINEAR',
> > > >>>>>>>>>>
> > > >>>>>>>>>> tAlpha=2.0E-04,
> > > >>>>>>>>>>
> > > >>>>>>>>>> sBeta=0.0,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # boundary conditions
> > > >>>>>>>>>>
> > > >>>>>>>>>> no_slip_sides=.FALSE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> no_slip_bottom=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # bottomDragLinear=1.1E-03,
> > > >>>>>>>>>>
> > > >>>>>>>>>> bottomDragQuadratic=0.0021,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # physical parameters
> > > >>>>>>>>>>
> > > >>>>>>>>>> f0=-0.9E-04,
> > > >>>>>>>>>>
> > > >>>>>>>>>> beta=1.0E-11,
> > > >>>>>>>>>>
> > > >>>>>>>>>> gravity=9.81,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # implicit diffusion and convective adjustment
> > > >>>>>>>>>>
> > > >>>>>>>>>> implicitDiffusion=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> implicitViscosity=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # exact volume conservation
> > > >>>>>>>>>>
> > > >>>>>>>>>> exactConserv=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # C-V scheme for Coriolis term
> > > >>>>>>>>>>
> > > >>>>>>>>>> useCDscheme=.FALSE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # partial cells for smooth topography
> > > >>>>>>>>>>
> > > >>>>>>>>>> hFacMin=5.0E-02,
> > > >>>>>>>>>>
> > > >>>>>>>>>> # file IO stuff
> > > >>>>>>>>>>
> > > >>>>>>>>>> readBinaryPrec=64,
> > > >>>>>>>>>>
> > > >>>>>>>>>> useSingleCpuIO=.TRUE.,
> > > >>>>>>>>>>
> > > >>>>>>>>>> debugLevel=1,
> > > >>>>>>>>>>
> > > >>>>>>>>>> &
> > > >>>>>>>>>
> > > >>>>>>>>>> _______________________________________________
> > > >>>>>>>>>> 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
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> 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
> > > >>
> > > >
> > > > _______________________________________________
> > > > MITgcm-support mailing list
> > > > MITgcm-support at mitgcm.org
> > > > http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >
> > > ________________________________
> > > This message (and any attachments) is for the recipient only. NERC is
> > subject to the Freedom of Information Act 2000 and the contents of this
> > email and any reply you make may be disclosed by NERC unless it is exempt
> > from release under the Act. Any material supplied to NERC may be stored in
> > an electronic records management system.
> > > ________________________________
> > > _______________________________________________
> > > 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
More information about the MITgcm-support
mailing list