<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Ah ok, so the GFS issue just happened to be at the same time.</div><div dir="ltr"><br></div><div dir="ltr">On the model crashing with time-step too long, the one I set up originally for you is a compromise. It is possible to always make the higher resolution runs complete (smaller time step) but will take longer to finish (or be too late to be of use).</div><div dir="ltr"><br></div><div dir="ltr">What I always suggest is again as said, which is to use the lower resolution model instead over. This will be almost the same for most parameters. </div><div dir="ltr"><br></div><div dir="ltr">However if looking for wave, then the lower resolution will probably not provide the detail to see on the plots. But for wind speed/direction, thermal height, cloud base, temperature, it will be about right. Where it probably won’t be right is across sharp ridges or topographically complex areas as the topographic model used, smooths these out.</div><div dir="ltr"><br></div><div dir="ltr">Ian: If you want something that checks the basic parameters against airport/airfield METAR reports for a ‘quality’ check, let me know.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr"><br></div><div dir="ltr">Darren</div><div dir="ltr"><br><blockquote type="cite">On 9 Apr 2026, at 10:16, Ian <ian@zomerlust.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="DejaVu Sans">There was one run which failed to
converge. Ie the model got into a loop where instead of each
step getting closer to a solution the results started to diverge
again. This leads to a model crash.</font></p>
<p><font face="DejaVu Sans">It is caused by an anomaly in the input
data - often associated with unusual weather events like "cut
off lows" (but that was not the cause of recent crashes).
This coupled with compromises made when the model was
constructed makes the model run crash. It happens on a handful
of runs a year.</font></p>
<p><font face="DejaVu Sans">In order to avoid this, the model would
have to have smaller "time step" intervals and/or a smaller
"resolution ratio" ie 12km -> 4km -> 1.3km. That would
make it run slower and use more computer time and electric
power. The parameters selected were a compromise that work most
of the time.</font></p>
<p><font face="DejaVu Sans">When this happens I have seen the same
date forecast crash on subsequent forecasts runs, ie 1 day
ahead, night before etc.</font></p>
<p><font face="DejaVu Sans">If you see this, have a look at the
alternate model legacy vs beta. It is possible one crashes when
the other manages to resolve.</font></p>
<p><font face="DejaVu Sans">Regards</font></p>
<p><font face="DejaVu Sans">Ian</font></p>
<p><font face="DejaVu Sans"><br>
</font></p>
<div class="moz-cite-prefix">On 4/8/26 20:40, AirSchool Paragliding
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPKYDukPiNb+hWhGodoEFu4nkaN2WJOONwPdxcxFk8gQbDhbkQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Greetings all<br>
<br>
Just noticed that a few <span class="Asgive ng" style="border-style:none;background:none">of the </span>RASP
days haven't been updated since yesterday e.g. RASP 1.3km d0 and
d2, RASP 2km d4 and d5<br>
<br>
Many thanks<br>
Ria</div>
</blockquote>
<span>-- </span><br><span>Rasp mailing list</span><br><span>Rasp@lists.zsd.co.za</span><br><span>https://lists.zsd.co.za/cgi-bin/mailman/listinfo/rasp</span><br></div></blockquote></body></html>