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

Jean-Michel Campin jmc at ocean.mit.edu
Mon May 12 15:50:39 EDT 2014


Hi Dimitris,
I don't know yet where to put this print warning.
will update CPP_EEOPTIONS.h (ready for this) and see where to put
the other bit.
Cheers,
Jean-Michel

On Mon, May 12, 2014 at 11:45:20AM -0700, Dimitris Menemenlis wrote:
> Jean-Michel, I agree.  Not a safe option to use, especially when debugging.
> Do you want me to take care of changes below, or will you do them.
> 
> Dimitris Menemenlis
> 
> On May 12, 2014, at 11:14 AM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> > Hi Dimitris,
> > 
> > I don't know if we should advertise too much this CPP option:
> > the effect is to discard any message (error/warning ...) from
> > any processor different from 0 (it will not transfert the error
> > message to STDERR.0000 but just drop it).
> > Now, many error messages are detected by all procs, but it's far to
> > be a general rule.
> > 
> > And before turning on this option, it seems to me that everything else
> > need to be checked (such as, in this case, monitorFreq) including 
> > how much wall clock time is really lost when all procs opening & write 
> > to STDOUT+STDERR.
> > The fact is, with the 3 suggestions you listed here:
> > http://mitgcm.org/pipermail/mitgcm-support/2009-April/006013.html
> > (+ also not to set debugMode=TRUE in eedata)
> > there is not much written in STDOUT after the initialisation is over.
> > 
> > I propose to change (again) the description of SINGLE_DISK_IO
> > in CPP_EEOPTIONS.h, by adding:
> > < C WARNING: to use only when absolutely confident that the setup is working
> > < C     since any message (error/warning/print) from any proc <> 0 will be lost.
> > but may be we should also add a warning in STDERR.0000 if this is turned on.
> > 
> > Cheers,
> > Jean-Michel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel



More information about the MITgcm-devel mailing list