[MITgcm-support] SSH problems with nonlinFreeSurf and Star
Stanislav Martyanov
martyanov.sd at gmail.com
Sun May 10 04:13:10 EDT 2020
Hello again!
It looks like I've found out what happens with SSH in my results.
The comparison of SSH and sea ice thickness distribution throughout the
model domain has shown that the negative SSH is co-located with thick ice.
I'm attaching the figure to illustrate this. Top Figs are eta, AREA and
HEFF simulated with deltaT=10 sec, the bottom Figs are the same but
simulated with deltaT=60 sec. All figures correspond to the same moment,
after 8 days of simulation. The date is Jan 8.
Is such SSH distribution OK when the sea ice is present? I mean - sharp
gradients in eta at the ice edges and polynyas?
Previously I was thinking that the modeled sea ice is just a some kind of
"foam plastic" floating on the water surface but not submerging... But
these SSH results suggest that when sea ise is present somewhere, the
actual SSH ( model's eta) at such regions is the ice's lower edge submerged
into the water.. Is that so?
Thanks!
Regards,
Stanislav
чт, 7 мая 2020 г. в 20:55, Stanislav Martyanov <martyanov.sd at gmail.com>:
> Thanks!
>
> чт, 7 мая 2020 г. в 19:26, Martin Losch <Martin.Losch at awi.de>:
>
>> I guess, these “DISABE_SOMETHING” or “EXCLUDE_SOMETHING” flags are not
>> documented, because they are not supposed to be set and should only be used
>> if you really know what you are doing. As far as I can see, they are
>> exclusively related to avoiding automatic differentiation of complicated
>> code with TAF or OpenAD.
>> If you cannot find the defined anywhere you are safe to assume, that they
>> are not defined. (and to make sure you can grep for them in your build
>> directory, e.g. “grep DISABLE_RSTAR_CODE *.h Makefile”, should show all
>> places where this flag could have been defined accidentally).
>>
>> Martin
>>
>> > On 7. May 2020, at 15:48, Stanislav Martyanov <martyanov.sd at gmail.com>
>> wrote:
>> >
>> > 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
>> > _______________________________________________
>> > 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/20200510/d38cbba4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SSHandICE.png
Type: image/png
Size: 402538 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20200510/d38cbba4/attachment-0001.png>
More information about the MITgcm-support
mailing list