<div dir="ltr">Hello Martin!<div><br></div><div>Thank you for your answer!</div><div><br></div><div>Having read the discussion at <a href="https://github.com/MITgcm/MITgcm/issues/171">https://github.com/MITgcm/MITgcm/issues/171</a> , 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).</div><div><br></div><div>>>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.<br></div><div>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.</div><div><br></div><div>Thanks again!</div><div>Stanislav.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 8 апр. 2021 г. в 08:43, 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">Hi Stanislav,<br>
<br>
I am sorry that you have trouble with stability.<br>
I run my simulations with these parameters:<br>
<br>
SEAICEnonLinIterMax = 10,<br>
LSR_ERROR = 1.e-5 (or smaller).<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Martin<br>
<br>
> On 7. Apr 2021, at 13:58, Stanislav Martyanov <<a href="mailto:martyanov.sd@gmail.com" target="_blank">martyanov.sd@gmail.com</a>> wrote:<br>
> <br>
> Hello!<br>
> <br>
> 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.<br>
> <a href="https://github.com/MITgcm/MITgcm/issues/171" rel="noreferrer" target="_blank">https://github.com/MITgcm/MITgcm/issues/171</a><br>
> <br>
> 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.<br>
> <br>
> I wonder if a consensus has been achieved in the MITgcm community for now about this tuning?<br>
> <br>
> 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.<br>
> <br>
> What can be a better remedy in this case:<br>
> 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?<br>
> 2) LSR is not good for high-res. Entirely switch to EVP solver (SEAICEuseEVPrev or SEAICEuseEVPstar?), everything is default.<br>
> <br>
> Thanks,<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>