[MITgcm-support] SSH problems with nonlinFreeSurf and Star

Thu May 7 09:48:17 EDT 2020

Hello, Martin!

>> but why would you want to set these parameters?
I asked because I dont really know if they are defined or undefined by
default.

I was examining the ECCO 4v4 code, and these keys were defined/undefined
there in CPP_OPTIONS. But they are absent in the default MITgcm code
downloaded from the website. I know that ECCO deals with adjoint, but I was
unaware that these keys are important only for adjoint.

More of it, I assumed, that if I want to use r* coordinate, then I should
somehow set/unset the flag DISABLE_RSTAR_CODE. Unfortunately, no word about
it in the manual and code.

чт, 7 мая 2020 г. в 16:33, Martin Losch <Martin.Losch at awi.de>:

> You can set these anywhere that will be seen globally, i.e the logical
> place remains to be CPP_OPTIONS.h,
>
> but why would you want to set these parameters? The only reason I can
> think of is the adjoint of the MITgcm, so that less code needs to be
> differentiated. If you don’t plan on doing that, then the default
> select_rStar = 0 will be enough.
>
> Martin
>
> > On 7. May 2020, at 14:30, Stanislav Martyanov <martyanov.sd at gmail.com>
> wrote:
> >
> > Hello!
> >
> > I still can't figure out  where do the keys DISABLE_RSTAR_CODE and
> DISABLE_SIGMA_CODE come from?
> >
> > In previous versions it was defined in CPP_OPTIONS, but now they are
> absent there. Are not these keys needed any more? But it is used in many
> checks throughout the code...
> >
> > пн, 4 мая 2020 г. в 12:55, Stanislav Martyanov <martyanov.sd at gmail.com>:
> > Hello, Martin!
> >
> > Thanks for your reply!
> > I'm stiil in the process of debugging the model. It looks like I had
> some problems with the river runoff, because when I switched it off - the
> SSH stoped oscillating so hard.
> >
> > But with the boundaries opened I have some negative sea level values
> which can not be explained by boundarys' forcing, so right now I am
> searching for the cause. May be the balancing through OBCS package should
> be configured differently (right now I have OBCS_balanceFacX = 1 along all
> open boundaries and  OBCS_balanceFacY = 0 along a closed one).
> >
> > I also suspect some possible issues with my vertical resolution (2m) and
> the minimum depth of the domain (5m, therefore only 2.5 layers exist in the
> shallowest regions). Perhaps I'll try to play somehow with it and with hFac
> parameters.
> >
> >
> >
> > пн, 4 мая 2020 г. в 11:51, Martin Losch <Martin.Losch at awi.de>:
> > Hi Stanislav,
> >
> > the nonlinear free surface is described in some detail in the
> documentation:
> > <
> https://mitgcm.readthedocs.io/en/latest/algorithm/nonlinear-freesurf.html>
> > inaccurate summary: “nonlinFreeSurf” is independent of select_rStar and
> you should probably only use nonlinFreeSurf=4, as the rest neglects various
> parts of the full implementation. r-star coordinates can only be used
> together with the nonlinear free surface so that the only two parameter
> settings that make sense to me are
> > nonlinFreeSurf=4
> > select_rStar =0 (for no r-star), and = 2 (if you want r-star).
> >
> > r-star is particularly useful if you vertical resolution is high
> (especially near the surface), as it prevents surface cell from running
> dry. But you can imagine that very low surface elevation will eventually
> make the model blow up anyway when all vertical cells are becoming too thin
> (your "STOP in CALC_R_STAR : too SMALL rStarFac[C,W,S]“ case)
> >
> > In order to debug your problem, I’d go with your option (4) (linear free
> surface), turn of OBCS (useOBCS=.FALSE.) and diagnose the net (surface)
> fresh water flux. Then the same with non-lnear free surface. In both cases
> the net surface freshwater flux will change your free surface, locally and
> in the mean (because you have exactConserv = .TRUE., useRealFreshWaterFlux
> = .TRUE.,), but in the linear case this does matter for the stability (but
> may affect your salinity so badly that is may become negative in extreme
> cases, that’s why a non-linear free surface makes more sense).
> > With a nonlinear free surface, this freshwater flux will lead to
> fluctuation in you free surface that affect the layer thickness. If the
> freshwater fluxes are realistic, the model should be able to handle them.
> >
> > There’s a flag (balanceEmPmR=.True.) that will balance your surface flux
> at each timestep so that the mean eta does not change, but is not very
> physical. You may have to adjust your surface freshwater flux (probably
> precip)
> >
> > OBCS implies additional volume fluxes into/out of the domain, that’s why
> it’s good to turn that off for debugging.
> > There are flags to balance that in each timestep, too, also together
> with the surface flux, but it’s better to have boundary conditions that
> have zero volume flux over physically sensible periods (e.g. full seasonal
> cycle, tidal cycle, …)
> >
> > Martin
> >
> >
> > > On 2. May 2020, at 00:57, Stanislav Martyanov <martyanov.sd at gmail.com>
> wrote:
> > >
> > > Hello everyone!
> > >
> > > Having tested my several MITgcm configurations (details here:
> http://mailman.mitgcm.org/pipermail/mitgcm-support/2020-April/012462.html)
> I encountered an issue with the model results. For unknown reasons the sea
> level has high oscillations and drops (up to  minus 3-6 m) which can not be
> explained by the prescribed external forcing and OBCS (they are OK, SSH =
> plus/minus 1 m at the boundary). Also, delR=2 m in the upper layers, and
> minimum depth in the domain is 5 m. No tides, no sponge.
> > >
> > > At each time step the model used SURF_ADJUSTMENT...
> > >
> > > Below are some parameters from the data file used for the reference
> run (№ 0):
> > >  &PARM01
> > >  hFacMin = 0.2,
> > >  hFacMinDr = 0.5,
> > >  hFacInf = 0.2,
> > >  hFacSup = 2.0,
> > >  vectorInvariantMomentum = .TRUE.,
> > >  highOrderVorticity = .TRUE.,
> > >  rigidLid = .FALSE.,
> > >  implicitFreeSurface = .TRUE.,
> > >  nonlinFreeSurf = 4,
> > >  select_rStar = 0,
> > >  exactConserv = .TRUE.,
> > >  useRealFreshWaterFlux = .TRUE.,
> > >  staggerTimeStep = .TRUE.,
> > >  multiDimAdvection = .TRUE.,
> > >  implicitViscosity = .TRUE.,
> > >  implicitDiffusion = .TRUE.,
> > >  viscAhGrid = 0.0,
> > >  viscAhGridMax = 0.5,
> > >  viscC2leith = 1.0,
> > >  viscC2leithD = 1.0,
> > >  useFullLeith = .TRUE.,
> > >  viscAr = 1.0e-4,
> > >  no_slip_sides = .FALSE.,
> > >  no_slip_bottom = .TRUE.,
> > >  bottomDragQuadratic = 0.0025,
> > >  tempAdvScheme = 33,
> > >  saltAdvScheme = 33,
> > >  diffKhT = 0.0,
> > >  diffKhS= 0.0,
> > >  diffKrT = 1.0e-4,
> > >  diffKrS = 1.0e-4,
> > >  useSingleCpuIO = .TRUE.,
> > >  &
> > >  forcing_In_AB = .FALSE.,
> > >  momDissip_In_AB = .FALSE.,
> > >  cAdjFreq = -1.0,
> > >  usingCurvilinearGrid = .TRUE.,
> > >
> > > Having spotted such erroneous results in STDOUT statistics, I started
> tuning some model's functionality to figure out what happened. Some
> conclusions for the subsequent runs:
> > > 1) I turn off the river runoff everywhere in OBCS. The problem
> remained.
> > > 2) + I removed eta boundary conditions from data.obcs.  The problem
> remained.
> > > 3) + I set useOBCS = .FALSE. in data.pkg, thus closed all the open
> boundaries, suspecting them. But the problem remained.
> > > 4) I returned to the initial settings (run № 0, see above), but set:
> nonlinFreeSurf = 0 and  linFSConserveTr = .TRUE., and the problem vanished,
> no SURF_ADJUSTMENT in the STDOUT any more!
> > > 5) I returned to the initial settings (run № 0, see above), but set:
> nonlinFreeSurf = 4 and  select_rStar = 2, , and get the followng message
> from one of tiles:
> > >  fail at i,j=  44  39 ; rStarFacC,H,eta =  0.199701  5.000000E+00
> -4.001496E+00
> > > WARNING: r*FacC < hFacInf at       1 pts : bi,bj,Thid,Iter=   1   1
>  1       350
> > > STOP in CALC_R_STAR : too SMALL rStarFac[C,W,S] !
> > >
> > > Could you please help me to figure out:
> > > a)  If I want to use non-linear free suface but do not want to use
> rStar, may I set  select_rStar=0 and nonlinFreeSurf=4 simultaniously? In
> the verification 'internal_wave' I found nonlinFreeSurf=3 and
> select_rStar=0. So, for select_rStar=0 the parameter  nonlinFreeSurf=0 is
> not a must?
> > > b) When selecting nonlinFreeSurf=4 and  select_rStar=2 the model
> crushes complaining  about too SMALL rStarFac[C,W,S]. My vertical
> resolution is too small (2 m) or I should change the hFacMin or hFacDr
> somehow?
> > > c) Where does the key DISABLE_RSTAR_CODE come from? It is used in many
> checks throughout the code, but I could not find where it is defined.
> Should I change it if I do not want to use rStar? Or using just
> select_rStar=0  is enough?
> > > d) Does the parameter hFacInf works only in the case of nonlinFreeSurf
> != 0, keeping the upper layer alive? What if I use nonlinFreeSurf= 0 and at
> some moment  -eta > dr(1)? The upper layer thickness may become 0 when
> nonlinFreeSurf=0?
> > >
> > > Thanks!
> > >
> > > Regards,
> > > Stanislav Martyanov
> > > _______________________________________________
> > > MITgcm-support mailing list
> > > MITgcm-support at mitgcm.org
> > > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20200507/81e3aa32/attachment-0001.html>