[MITgcm-support] SSH problems with nonlinFreeSurf and Star

Thu May 7 08:30:30 EDT 2020

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