[MITgcm-support] how many timesteps?

[Martin Losch]

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
>