[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