[MITgcm-support] Effect of 'vectorInvariantMomentum' flag on first order circulation

Jean-Michel Campin jmc at mit.edu
Wed Mar 8 19:46:39 EST 2017


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



More information about the MITgcm-support mailing list