[MITgcm-support] SSH problems with nonlinFreeSurf and Star

[Stanislav Martyanov]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20200504/35aa6430/attachment-0001.html>