<div dir="ltr"><div>Hello, Martin!</div><div><br></div>>>
but why would you want to set these parameters?<div>I asked because I dont really know if they are defined or undefined by default.</div><div><br><div>I was examining the ECCO 4v4 code, and these keys <font color="#000000">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.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">More of it, I assumed, that if I want to use r* coordinate, then I should somehow set/unset the flag <span style="letter-spacing:0.2px;white-space:nowrap">DISABLE_RSTAR_CODE. Unfortunately, no word about it in the manual and code.</span></font></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 7 мая 2020 г. в 16:33, Martin Losch <<a href="mailto:Martin.Losch@awi.de">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">You can set these anywhere that will be seen globally, i.e the logical place remains to be CPP_OPTIONS.h,<br>
<br>
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.<br>
<br>
Martin<br>
<br>
> On 7. May 2020, at 14:30, Stanislav Martyanov <<a href="mailto:martyanov.sd@gmail.com" target="_blank">martyanov.sd@gmail.com</a>> wrote:<br>
> <br>
> Hello!<br>
> <br>
> I still can't figure out where do the keys DISABLE_RSTAR_CODE and DISABLE_SIGMA_CODE come from?<br>
> <br>
> 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...<br>
> <br>
> пн, 4 мая 2020 г. в 12:55, Stanislav Martyanov <<a href="mailto:martyanov.sd@gmail.com" target="_blank">martyanov.sd@gmail.com</a>>:<br>
> Hello, Martin!<br>
> <br>
> Thanks for your reply!<br>
> 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.<br>
> <br>
> 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).<br>
> <br>
> 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.<br>
> <br>
> <br>
> <br>
> пн, 4 мая 2020 г. в 11:51, Martin Losch <<a href="mailto:Martin.Losch@awi.de" target="_blank">Martin.Losch@awi.de</a>>:<br>
> 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>
> _______________________________________________<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>