# [MITgcm-support] Crashes with EVP seaice

Pochini, Enrico epochini at inogs.it
Sat Jan 23 12:37:57 EST 2021

Got it!

Here are my sea-ice fields for the three cases.
https://drive.google.com/file/d/1ReoThY1c-YL1OmiOy3S9Pp5Pt5WT-e83/view?usp=sharing

I will try Nikolay's ones and see the difference and performance.

Kind regards,

Enrico

Il giorno ven 22 gen 2021 alle ore 17:22 Martin Losch <Martin.Losch at awi.de>
ha scritto:

> Hi Enrico,
>
> SEAICEaEVPcoeff is the tuning parameter for aEVP. The other parameters can
> be modified as well, but this one is the only one that we normally change.
> Please have a look again here:
> <
> https://mitgcm.readthedocs.io/en/latest/phys_pkgs/seaice.html#more-stable-variants-of-elastic-viscous-plastic-dynamics-evp-mevp-and-aevp
> >
> and compare eq. 8.19 with A22 in Koldunov et al. Their c_aEVP is “our”
> \tilde{c}\sqrt{c}; c=SEAICEaEVPcstar=4 by default so
> SEAICEaEVPcoeff=\tilde{c} = 0.5 is appromately c_aEVP = 0.5* 2 = 1
> and I think that the pi is missing in A22 (it’s still there in the
> beginning of the paragraph before).
> Note that Nikolay (Koldunov) used 50 for the minimum alpha, the default
> for the MITgcm is 5, but that shouldn’t make too much of a difference. And
> yes, it’s stupid to have two multiplicative parameters in the model, that
> has historical reasons connected to the stability analysis of the Kimmritz
> et al. 2016 paper. I should get rid of that.
>
> I’d be interested to see the differences. In general I trust the Picard
> solver more than any of the EVP solvers, but with a properly tuned mEVP or
> with aEVP the results should not be too different.
>
> Martin
>
> > On 22. Jan 2021, at 17:03, Pochini, Enrico <epochini at inogs.it> wrote:
> >
> > Hi Martin,
> >
> > Eventually I went around the problem and used the LSR Picard solver.. I
> also had a problem with surface fluxes giving wild summer warming, which I
> fixed, so the sea ice I get with Picard is not absurd anymore.
> > I've followed your advice and run two other experiments with same setup
> using aEVP with the parameters as in the manual section:
> >  SEAICEuseEVPstar=.true.,
> >  SEAICEuseEVPrev=.true.,
> >  SEAICEaEVPcoeff = 0.5,
> >  SEAICEnEVPstarSteps=500,
> >
> > and another with
> > SEAICEnEVPstarSteps=200,
> >
> > These runs didn't crash and ran for 8 years.
> > There are some differences between the three cases, especially between
> aEVP (starSteps=500) and LSR, especially close to the coast, with LSR
> having more often open water. All the three develop cracks and features.
> However the aEVP with 500 starSteps is 50% slower than LSR. (aEVP with 200
> steps only 15% slower). The two EVPs are similar, except the timing of
> appearance of features which may differ slightly.
> >
> > I can send a link to the output if you would like to have a look. I'm
> yet unsure which one would be better to use...
> > I wonder which of the two SEAICEaEVPcStar or the SEAICEaEVPcoeff is the
> tuning parameter c aEVP in Koldunov et al 2019:  (set to 1.5 after tuning)
> >
> > Thank you Martin,
> >
> > Enrico
> >
> >
> >
> >
> > Il giorno gio 21 gen 2021 alle ore 12:46 Martin Losch <
> Martin.Losch at awi.de> ha scritto:
> > Hi Enrico,
> >
> > did you get anywhere with this?
> >
> > The error just means, that the model has exploded (and MOM_IMPLICIT_R is
> probably the first routine in the new timestep that notices that). If you
> want more output, the first thing to do is set the monitorFreq to 1.
> >
> > The EVP solver is not my preferred choice, and I don’t plan to do too
> much more development there, so that’s why the debugging information is
> sparse. You’ll have to add your debugging information yourself.
> >
> > If you really need to use EVP, I suggest that you use the mEVP (as you
> do) or aEVP. For mEVP the alpha/beta values should be at least order 100 if
> not 500 in your case (see Kimmritz et al papers, 20 is definitely too
> small). aEVP is probably even better (because it sets alpha/beta somewhat
> dynamically). Please try the parameter set recommended at the end of this
> section in the documentation: <
> https://mitgcm.readthedocs.io/en/latest/phys_pkgs/seaice.html#more-stable-variants-of-elastic-viscous-plastic-dynamics-evp-mevp-and-aevp
> >
> > There’s no guarantee that the solver is stable at all times, but the
> better (smoother) the convergence the larger the chance of good behavior.
> aEVP is a good way of doing that.
> >
> > Otherwise I recommend the default Picard solver. I am surprised that it
> gives very different ice solutions (usually the differences are small, and
> usually the EVP solver give the funny solutions).
> >
> > The ice field is suprisingly smooth at this resolution, another
> indication that the EVP solver does not converge properly (see eg. Koldunov
> et al 2019, https://doi.org/10.1029/2018MS001485).
> >
> > Martin
> >
> >
> > > On 7. Jan 2021, at 15:33, Pochini, Enrico <epochini at inogs.it> wrote:
> > >
> > > Dear community,
> > >
> > > I am trying to run a regional model with SHELFICE and SEAICE packages.
> > > However I'm still having problems with crashes while employing the EVP
> solver.
> > >
> > > The error I get is the general
> > > ERROR STOP MOM_IMPLICIT_R: error when solving 3-Diag problem.
> > > and I only get it with the EVP; with the LSR solver the model runs
> fine for more years but the ice I get seems to be less realistic.
> > >
> > > I was able to run the model for just two years with EVP without
> crashes with the namelist files attached.
> > >
> > > To restart the model I have tried playing with OBCS_SEAICE options,
> sponge layer thickness and relaxation times and EVP alpha/beta parameters
> (from 10 to 600). I tried also disabling OB for seaice. I have 5km
> resolution, 300 seconds deltaT, vertical levels with min 10m thickness.
> > >
> > > Can you point me to some tests to fix this problem?
> > > How can I print debugging information in the STDOUT? In the
> SEAICE_OPTIONS.h I set #define SEAICE_DEBUG and have debugLevel>0 in "data"
> but it doesn't seem to work with EVP.
> > >
> > > Kind regards,
> > >
> > > Enrico
> > >
> > >
> <data><data.seaice><data.obcs>_______________________________________________
> > > 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/20210123/5295f0d3/attachment.html>


More information about the MITgcm-support mailing list