<div dir="ltr">Hello, Dafydd,<div><br></div><div>Some time ago I had a similar problem with the thickness of the upper layer, though I do not use z* now. The cause of it was (in my opinion) the seaice model. Nevertheless, in my run there was not multi-year accumulation of sea ice, and also there were no thin bays in the domain (no 1-2 cell thickness, I checked). Thanks to Martin's suggestion, the modification of two parameters helped to solve the problem in data.seaice:</div><div><br></div><div>SEAICEnonLinIterMax = 10,<br>LSR_ERROR = 1.e-5<br></div><div><br></div><div>After this the problem vanished, though the changing of the ice loading can also affect the problem. In my case, I changed the initial code in seaice_growth and SEAICE.h, to work this HEFF rather than iceload. In fact, it really affects only 4-5 cells in my domain, so it is not a problem.</div><div><br></div><div>Best wishes,</div><div>Stanislav Martyanov.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 25 окт. 2021 г. в 22:53, Dafydd Stephenson <<a href="mailto:dafydd@ucar.edu">dafydd@ucar.edu</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">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-725171619825442233WordSection1">
<p class="MsoNormal"><span lang="EN-GB">Hi everyone,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">all of my runs seem to eventually (after a few model decades) exit with the error “ STOP in CALC_R_STAR : too SMALL rStarFac[C,W,S] ! ”. I am running the ECCOv4r4 configuration with CORE Normal Year Forcing.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">I have enabled monitoring at the timestep frequency, and, as the forcing repeats yearly, comparing the monitoring statistics with those of the previous year seems useful. Plotting them shows that they are comparable until
 the point of the error (at which point one of the line plots stops suddenly while the other continues), so I don’t believe there to be a CFL violation or any sort of runaway instability. Similarly, I have balanceEmPmR=.TRUE., so I don’t think that a cell is
 running dry.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Nevertheless, the error seems to occur in the same location every time (processor 94 of 192 [or 47 of 96, depending on the config], at i,j=2,13), and I think it would be useful to know exactly where this is. Is there
 some way I could get from this CPU,j,i location to an index of the llc90 grid?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Thanks in advance for any help,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Dafydd<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
</div>
</div>

_______________________________________________<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>