[MITgcm-support] how many timesteps?

[Jonny Williams]

Hi Martin

Thanks a lot for that. That makes sense. I had previously used the
following...

grep -i "OBCS_CALC: East" STDOUT.0000|wc -l

... but this would only work when using the OBCS package!

Cheers

Jonny


On 5 March 2015 at 09:01, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi Jonny,
>
> I need to correct my statement a little (not about the monitorFreq, but
> about the debugLevel).
>
> As long as you have debugLevel=-1, there will be basically no extra output
> from the model, except for the stuff that you ask for explicitly (such as
> monitor output).
>
> already with debugLevel=1 you’ll have output from the pressure solve at
> every time step and as was pointed out by Patrick (off this list),
>
> grep ‘cg2d:’ STDOUT.0000 | wc -l
>
> will give you the number of time steps, unless your system uses large
> buffers that are not flushed when the model crashes. So setting the
> debugLevel does have an effect on the amount of output that you’ll get (but
> not on the monitor output).
>
> Martin
>
> > On 03 Mar 2015, at 15: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/20150305/cd21373f/attachment.htm>