[Developers] [Patches] Output parameter warnings to stdout as well
schnetter at cct.lsu.edu
Fri Dec 4 23:06:05 CST 2009
On Sep 15, 2009, at 14:40 , Erik Schnetter wrote:
> On Sep 11, 2009, at 12:00 , Ian Hinder wrote:
>> On 11 Sep 2009, at 15:46, Frank Loeffler wrote:
>>> On Fri, Sep 11, 2009 at 10:21:55AM +0800, Erik Schnetter wrote:
>>>> The enclosed patch outputs parameter warnings and parameter errors to
>>>> stdout as well. Different from regular warnings, they are currently
>>>> only output to stderr. This is inconvenient, since stderr collects
>>>> warnings from all processors, and thus contains many repetitions of
>>>> the same error messages.
>>> This creates another inconvenience: when simply run interactivly,
>>> is now one more warning output, in addition to all the others from
>>> stderr. Even when running on with one process a warning is now printed
>>> twice. I don't think this is optimal.
>>> I wonder if it wouldn't be better to only emit warnings for parameter
>>> file settings once, on the root processor, and only print them to
>>> stderr. Each process parses the same parameter file and should come to
>>> the same warnings anyway.
>> Why are we printing errors and warnings to standard error anyway? I
>> think it causes more trouble than it is worth. Can you think of a
>> good reason why we don't output everything to standard output?
> The original idea was that everything should go to stdout, while important warnings and errors should also go to stderr. stdout is often quite noise, and if something goes seriously wrong, then a glance at stderr should give a first idea of where the problem lies. Additionally, since stdout captures only output from the root process, it is important to see the important warnings and errors from the other processes. We can certainly play with what should be output into what file, with the caveat that outputting everything to files is too expensive when running at >1000 processes.
>> The reason for having two separate streams is related to Unix programs
>> whose output is machine-readable data which may be passed to another
>> program through a pipe. In that situation, it would be bad for that
>> data to be corrupted with error or warning messages. Since Cactus
>> output is freeform, this does not apply here.
>> On supercomputers, stdout and stderr are usually sent to two separate
>> files. When checking to see the status of a simulation, first you
>> have to check stdout, then go and check stderr to find the actual
>> reason for the failure. If everything was in stdout this would not be
>> necessary. The split also makes it harder to get a complete picture
>> if you ware watching the output of a simulation in realtime (tail -f
>> outfile) as the errors and warnings don't appear in the output file.
> I agree that everything should go to stdout. I believe that the parameter warnings are the only case where something is only output to stderr.
I have just committed the patch.
The problem that you mention, namely that the same error message is multiplied on stderr for each MPI process, is still present.
Erik Schnetter <schnetter at cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/
More information about the Developers