<div dir="ltr">Hello!<div><br><div>I still can't figure out <span style="font-family:arial,sans-serif"> w</span><span style="font-family:arial,sans-serif">here do the keys DISABLE_RSTAR_CODE and </span>DISABLE_SIGMA_CODE <span style="font-family:arial,sans-serif">come from?</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">In previous versions it was defined in CPP_OPTIONS, but now they are absent there. Are not these keys needed any more? But i</span><span style="font-family:arial,sans-serif">t is used in many checks throughout the code...</span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 4 мая 2020 г. в 12:55, Stanislav Martyanov <<a href="mailto:martyanov.sd@gmail.com">martyanov.sd@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello, Martin!<div><br></div><div>Thanks for your reply!</div><div>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.</div><div><br></div><div>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).
</div><div><br></div><div>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. </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 4 мая 2020 г. в 11:51, Martin Losch <<a href="mailto:Martin.Losch@awi.de" target="_blank">Martin.Losch@awi.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Stanislav,<br>
<br>
the nonlinear free surface is described in some detail in the documentation:<br>
<<a href="https://mitgcm.readthedocs.io/en/latest/algorithm/nonlinear-freesurf.html" rel="noreferrer" target="_blank">https://mitgcm.readthedocs.io/en/latest/algorithm/nonlinear-freesurf.html</a>><br>
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<br>
nonlinFreeSurf=4<br>
select_rStar =0 (for no r-star), and = 2 (if you want r-star).<br>
<br>
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)<br>
<br>
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).<br>
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.<br>
<br>
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)<br>
<br>
OBCS implies additional volume fluxes into/out of the domain, that’s why it’s good to turn that off for debugging. <br>
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, …)<br>
<br>
Martin<br>
<br>
<br>
> On 2. May 2020, at 00:57, Stanislav Martyanov <<a href="mailto:martyanov.sd@gmail.com" target="_blank">martyanov.sd@gmail.com</a>> wrote:<br>
> <br>
> Hello everyone!<br>
> <br>
> Having tested my several MITgcm configurations (details here: <a href="http://mailman.mitgcm.org/pipermail/mitgcm-support/2020-April/012462.html" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/pipermail/mitgcm-support/2020-April/012462.html</a>) 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.<br>
> <br>
> At each time step the model used SURF_ADJUSTMENT...<br>
> <br>
> Below are some parameters from the data file used for the reference run (№ 0):<br>
> &PARM01<br>
> hFacMin = 0.2,<br>
> hFacMinDr = 0.5,<br>
> hFacInf = 0.2,<br>
> hFacSup = 2.0,<br>
> vectorInvariantMomentum = .TRUE.,<br>
> highOrderVorticity = .TRUE.,<br>
> rigidLid = .FALSE.,<br>
> implicitFreeSurface = .TRUE.,<br>
> nonlinFreeSurf = 4,<br>
> select_rStar = 0,<br>
> exactConserv = .TRUE.,<br>
> useRealFreshWaterFlux = .TRUE.,<br>
> staggerTimeStep = .TRUE.,<br>
> multiDimAdvection = .TRUE.,<br>
> implicitViscosity = .TRUE.,<br>
> implicitDiffusion = .TRUE.,<br>
> viscAhGrid = 0.0,<br>
> viscAhGridMax = 0.5,<br>
> viscC2leith = 1.0,<br>
> viscC2leithD = 1.0,<br>
> useFullLeith = .TRUE.,<br>
> viscAr = 1.0e-4,<br>
> no_slip_sides = .FALSE.,<br>
> no_slip_bottom = .TRUE.,<br>
> bottomDragQuadratic = 0.0025,<br>
> tempAdvScheme = 33,<br>
> saltAdvScheme = 33,<br>
> diffKhT = 0.0,<br>
> diffKhS= 0.0,<br>
> diffKrT = 1.0e-4,<br>
> diffKrS = 1.0e-4,<br>
> useSingleCpuIO = .TRUE.,<br>
> &<br>
> forcing_In_AB = .FALSE.,<br>
> momDissip_In_AB = .FALSE.,<br>
> cAdjFreq = -1.0,<br>
> usingCurvilinearGrid = .TRUE.,<br>
> <br>
> 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:<br>
> 1) I turn off the river runoff everywhere in OBCS. The problem remained.<br>
> 2) + I removed eta boundary conditions from data.obcs. The problem remained.<br>
> 3) + I set useOBCS = .FALSE. in data.pkg, thus closed all the open boundaries, suspecting them. But the problem remained.<br>
> 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!<br>
> 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:<br>
> fail at i,j= 44 39 ; rStarFacC,H,eta = 0.199701 5.000000E+00 -4.001496E+00<br>
> WARNING: r*FacC < hFacInf at 1 pts : bi,bj,Thid,Iter= 1 1 1 350<br>
> STOP in CALC_R_STAR : too SMALL rStarFac[C,W,S] !<br>
> <br>
> Could you please help me to figure out:<br>
> 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?<br>
> 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?<br>
> 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?<br>
> 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?<br>
> <br>
> Thanks!<br>
> <br>
> Regards,<br>
> Stanislav Martyanov<br>
> _______________________________________________<br>
> MITgcm-support mailing list<br>
> <a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
> <a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
<br>
_______________________________________________<br>
MITgcm-support mailing list<br>
<a href="mailto:MITgcm-support@mitgcm.org" target="_blank">MITgcm-support@mitgcm.org</a><br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support</a><br>
</blockquote></div>
</blockquote></div>