<div dir="ltr"><div>Hi Martin,</div><div><br></div><div>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.<br></div><div>I've followed your advice and run two other experiments with same setup using aEVP with the parameters as in the manual section:</div><div style="margin-left:40px"> SEAICEuseEVPstar=.true.,</div><div style="margin-left:40px"> SEAICEuseEVPrev=.true.,<br> SEAICEaEVPcoeff = 0.5,</div><div style="margin-left:40px"> SEAICEnEVPstarSteps=500,</div><div><br></div><div>and another with <br></div><div style="margin-left:40px">SEAICEnEVPstarSteps=200,</div><div></div><div><br></div><div>These runs didn't crash and ran for 8 years. <br></div><div>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. <br></div><div><br></div><div>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...<br></div><div>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)<br></div><div><br></div><div>Thank you Martin,</div><div><br></div><div>Enrico<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 21 gen 2021 alle ore 12:46 Martin Losch <<a href="mailto:Martin.Losch@awi.de">Martin.Losch@awi.de</a>> ha scritto:<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 Enrico,<br>
<br>
did you get anywhere with this?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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: <<a href="https://mitgcm.readthedocs.io/en/latest/phys_pkgs/seaice.html#more-stable-variants-of-elastic-viscous-plastic-dynamics-evp-mevp-and-aevp" rel="noreferrer" target="_blank">https://mitgcm.readthedocs.io/en/latest/phys_pkgs/seaice.html#more-stable-variants-of-elastic-viscous-plastic-dynamics-evp-mevp-and-aevp</a>><br>
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.<br>
<br>
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).<br>
<br>
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, <a href="https://doi.org/10.1029/2018MS001485" rel="noreferrer" target="_blank">https://doi.org/10.1029/2018MS001485</a>).<br>
<br>
Martin<br>
<br>
<br>
> On 7. Jan 2021, at 15:33, Pochini, Enrico <<a href="mailto:epochini@inogs.it" target="_blank">epochini@inogs.it</a>> wrote:<br>
> <br>
> Dear community,<br>
> <br>
> I am trying to run a regional model with SHELFICE and SEAICE packages. <br>
> However I'm still having problems with crashes while employing the EVP solver. <br>
> <br>
> The error I get is the general <br>
> ERROR STOP MOM_IMPLICIT_R: error when solving 3-Diag problem.<br>
> 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. <br>
> <br>
> I was able to run the model for just two years with EVP without crashes with the namelist files attached.<br>
> <br>
> 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.<br>
> <br>
> Can you point me to some tests to fix this problem? <br>
> 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. <br>
> <br>
> Kind regards,<br>
> <br>
> Enrico<br>
> <br>
> <data><data.seaice><data.obcs>_______________________________________________<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>