[MITgcm-support] reducing the size of STDOUT files etc

Martin Losch Martin.Losch at awi.de
Mon May 12 08:38:21 EDT 2014


Hi Jonny,

each process will create it’s own pair of STDOUT/STDERR, not much you can do about it without hacking the code.

But I saw that your monitorFreq = 1. 
this means that’s you’ll get output every timestep (and in all STDOUT.*). This appears to be an overkill for a “production” run (where you don’t test things any longer), will make the model very slow and the STDOUT-files very large. For a production run I usually use a monitorFreq = 20-50*deltaT.

M.

On May 12, 2014, at 1:58 PM, Jonny Williams <Jonny.Williams at bristol.ac.uk> wrote:

> Hi there
> 
> I am trying to reduce the size of the output from my model because I am running on a very large number of processors and all the STDOUT* files (for example) are taking up too much space.
> 
> I've followed the instructions on this MITgcm support page...
> 
> http://mitgcm.org/pipermail/mitgcm-support/2009-April/006013.html
> 
> ... but I am still getting a STDOUT file for every processor (>1000) which is killing my disk space allowance! Is there something that I've missed? I thought that running with useSingleCpuIO=.TRUE. should mean that I only get 1 STDOUT file? I've attached my data file in case anyone has any ideas as to what is going wrong?!
> 
> Many thanks for your help.
> 
> Jonny
> 
> -- 
> Dr Jonny Williams
> School of Geographical Sciences
> University of Bristol
> University Road
> BS8 1SS
> 
> +44 (0)117 3318352
> jonny.williams at bristol.ac.uk
> bit.ly/jonnywilliams
> <data>_______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list