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

Andrea Cimatoribus andrea.cimatoribus at epfl.ch
Wed Mar 8 02:59:21 EST 2017


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
>



More information about the MITgcm-support mailing list