[MITgcm-support] seaice, LSR_ERROR, EVP

[Stanislav Martyanov]

Hello Martin!

Thank you for your answer!

Having read the discussion at https://github.com/MITgcm/MITgcm/issues/171 ,
I agree with you that these new parameters should be set as defaults in
MITgcm. Just as an MITgcm user's opinion: it would be better if the model
'from the box'  would be rather stable than fast. Finding a user's
configuration's problems in a case when the model crashes, and then
repeating model runs, will anyway consume computational time (and user's
time as well).

>>I cannot exclude that model explosions (NaN) originate from the sea ice
solver, but in most instances that I have seen this is not directly due to
the solver, but indirectly, by creating surface boundary conditions for the
ocean model that then lead to violation >>of CFL etc.
I have checked meteo forcing and do not use masked meteo fields as input to
avoid problems with interpolation into the model's grid, etc. Moreover,
serious errors with forcing, as I see it, would crash the model with any
time step. Of course, some specific violations may arise in theory. For
instance, rapid sea ice formation -> strong salinification -> high vertical
velocities, but such things should be solved by convective adjustment or
enhanced mixing.

Thanks again!
Stanislav.

чт, 8 апр. 2021 г. в 08:43, Martin Losch <Martin.Losch at awi.de>:

> Hi Stanislav,
>
> I am sorry that you have trouble with stability.
> I run my simulations with these parameters:
>
> SEAICEnonLinIterMax = 10,
> LSR_ERROR = 1.e-5 (or smaller).
>
> The first one makes the lsr solver run 5 times longer than the default,
> the second one usually increases runtime only a little with the benefit
> that the parallelization improves dramatically (especially at higher
> resolution). I think that this has been discussed often here and elsewhere
> (or at least it feels that I explain this to someone almost once a week,
> maybe not in an email). The main reason that these value have not made it
> as defaults is the extra run-time that we would like to avoid for some
> large set-ups (where the maintainers have bigger issues than fiddling with
> the sea ice model).
>
> I do not recommend to use EVP to avoid instabilities in a ice-ocean
> simulation. In my experience, the LSR is far more stable than the EVP
> solver, especially at high resolution. The reason is, that both solvers do
> not converge (ever in a realistic configuration), because it’s a very stiff
> problem (see the literature about it), but the LSR solver moves the
> momentum state towards convergence in a smooth way (intermediate solution
> steps are smooth), while the EVP solver is always a little noisy. The EVP
> noise reduces, when you use many iterations and there are ways to speed
> this up (again, see literature, e.g. Kimmritz et al), but in my experience,
> the chances of some noise surviving the EVP iteration are larger than for
> any poorly converged LSR solution.
>
> I cannot exclude that model explosions (NaN) originate from the sea ice
> solver, but in most instances that I have seen this is not directly due to
> the solver, but indirectly, by creating surface boundary conditions for the
> ocean model that then lead to violation of CFL etc.
>
> Martin
>
> > On 7. Apr 2021, at 13:58, Stanislav Martyanov <martyanov.sd at gmail.com>
> wrote:
> >
> > Hello!
> >
> > Recently I've found a conversation at github about possible problems
> with the seaice package related to too large LSR_ERROR value set by default
> to 1.0e-4.
> > https://github.com/MITgcm/MITgcm/issues/171
> >
> > In that topic it was suggested to use a smaller value of LSR_ERROR:
> 1.0e-5 or 1.0e-6, for convergence reasons. It was in 2019.
> >
> > I wonder if a consensus has been achieved in the MITgcm community for
> now about this tuning?
> >
> > This question has arisen because I periodically get NaNs (I suspect it
> is because of sea ice) in a high-res model with resolution O(1 km). It
> occurs during the melting period in summer. Reducing the deltaT from 120
> sec to 90 solved the problem, but it occurred again already with 90 sec in
> the next month . Surprisingly, returning back to 120 sec allowed me to get
> through it. I use the default LSR solver and suspect that the problem may
> be a bed convergence of the sea ice model.
> >
> > What can be a better remedy in this case:
> > 1) continue to use LST solver but set LSR_ERROR  = 1.0e-5, everything
> else is default. Should I also change SEAICEnonLinIterMax in this case from
> default 2 to 10?
> > 2) LSR is not good for high-res. Entirely switch to EVP solver
> (SEAICEuseEVPrev or SEAICEuseEVPstar?), everything is default.
> >
> > Thanks,
> > 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/20210408/26ab6b0e/attachment.html>