[MITgcm-support] how many timesteps?

[Jonny Williams]

Hi Martin

Thanks very much as usual for your very informative help. I look forward to
possibly getting hold of Paul Holland's code as you mention!

Cheers

Jonny

On 3 March 2015 at 14:16, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi there,
>
> the monitor package is indeed quite useful, but it will only give you the
> statistics of a snapshot every “monitorFreq” seconds. So if you time step
> is deltaT=100 and your monitorFreq = 1000, then you’ll get output every 10
> time steps. If the model dies in-between, there will be no extra output,
> because the monitor package will be called only every 10 time steps.
> Setting monitorFreq = 100 or any value < deltaT will give you output every
> timestep, but will make the model very slow, so it is useful only if you
> have to run a relatively small amount of time steps before the model
> crashes.
>
> I remember that Paul Holland once implemented a hack to have the model
> output some stuff before it dies. Paul, maybe you can share this code.
>
> Jonny, in any case you’ll have to rerun your model with smaller
> monitorFreq. The debugLevel doesn’t have anything to do with this.
>
> Martin
>
> > On 03 Mar 2015, at 13:42, Jonny Williams <Jonny.Williams at bristol.ac.uk>
> wrote:
> >
> > Thanks very much for that Ed
> >
> > Unfortunately that output isn't present in my STDOUT* files. I think
> this is because I have debugMode=.FALSE., in my eedata file and
> debugLevel=-1, in my data file?
> >
> > Cheers
> >
> > Jonny
> >
> >
> > On 3 March 2015 at 12:22, Edward Doddridge <
> edward.doddridge at magd.ox.ac.uk> wrote:
> > Hi Jonny,
> >
> > The STDERR.00* files should show you how many iterations the model ran
> for before it died. Here's an example from a run that stopped after 20
> timesteps.
> >
> > (PID.TID 0000.0001) SOLUTION IS HEADING OUT OF BOUNDS: tMin,tMax=
> -1.255E+03  1.589E+03
> > (PID.TID 0000.0001)   exceeds allowed range (monSolutionMaxRange=
> 1.000E+03)
> > (PID.TID 0000.0001) MON_SOLUTION: STOPPING CALCULATION at Iter=        20
> > (PID.TID 0000.0001) *** ERROR *** S/R ALL_PROC_DIE: ending the run
> >
> > If you want to monitor how a run is going before it dies, the monitor
> package is the easiest way I know of.  "monitorFreq" in PARAM03 in the data
> file sets the frequency of the output. It's a very cheap way to dump data
> regularly. If you know deltaT and the monitorFreq, then you can work out
> the number of iterations the model has done.
> >
> > Best,
> > Ed
> >
> > ________________________________
> > Edward Doddridge
> > Doctoral Student
> > Atmospheric, Oceanic and Planetary Physics
> > University of Oxford
> >
> > www.doddridge.me
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>



-- 
Dr Jonny Williams
School of Geographical Sciences
Cabot Institute
University of Bristol
BS8 1SS

+44 (0)117 3318352
jonny.williams at bristol.ac.uk
http://www.bristol.ac.uk/geography/people/jonny-h-williams
<http://bit.ly/jonnywilliams>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20150303/32170ea8/attachment.htm>