Project

General

Profile

Bug #2211

gmx writes normal output to stderr

Added by Daniel Bauer over 2 years ago. Updated over 1 year ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Hello,

I recently noticed that all gmx commands write their output to stderr instead of stdout. Wouldnt it be better for logging etc to have normal output in stdout?

Best regards,
Daniel


Related issues

Related to GROMACS - Task #1505: improve handling of loggingNew

History

#1 Updated by Mark Abraham over 2 years ago

Daniel Bepunkt wrote:

Hello,

I recently noticed that all gmx commands write their output to stderr instead of stdout. Wouldnt it be better for logging etc to have normal output in stdout?

I wouldn't say "all" ;-) The only consistent thing about GROMACS in this regard is inconsistency.

IMO the "normal output" should go to stdout, and anything that helps reacting to a terminating error condition should go to stderr. So gmx pdb2gmx -h writes the usage to stdout, but gmx pdb2gmx -broken writes the usage to stderr. Progress reports (e.g. which step or frame the tool is currently handling) should be written only if the terminal is interactive (e.g. using isatty()), and in that case, to stdout.

This is merely one aspect of the long-overdue overhaul of how gmx tools do logging... Teemu wrote some nice infrastructure, but we haven't taken much advantage of it, yet.

Relevant discussion at https://unix.stackexchange.com/questions/331611/do-progress-reports-logging-information-belong-on-stderr-or-stdout

#2 Updated by Mark Abraham over 2 years ago

  • Related to Task #1505: improve handling of logging added

#3 Updated by Daniel Bauer over 2 years ago

Thanks for your response!
Great to see that I am not the only one who thinks that this is in need of an overhaul!

#4 Updated by Mark Abraham over 2 years ago

Daniel Bepunkt wrote:

Thanks for your response!
Great to see that I am not the only one who thinks that this is in need of an overhaul!

Ah, but do you have the stomach to help out? ;-)

#5 Updated by Szilárd Páll over 2 years ago

Side-note: some (most?) of the use of messages to stderr in mdrun was motivated by console message aggregation with MPI. Not sure to what extent have things changed recently, but stuff like LINCS or settle warnings that are sometimes precursors can be followed of an (expected) mdrun crash, even with a well-implemented console message aggregation, messages could be lost if MPI does not gather them.

#6 Updated by Mark Abraham over 1 year ago

Szilárd Páll wrote:

Side-note: some (most?) of the use of messages to stderr in mdrun was motivated by console message aggregation with MPI. Not sure to what extent have things changed recently, but stuff like LINCS or settle warnings that are sometimes precursors can be followed of an (expected) mdrun crash, even with a well-implemented console message aggregation, messages could be lost if MPI does not gather them.

If e.g. a (multi-sim) master rank would play the role of aggregator, then e.g. for terminal-mode mdrun we could have a single message that the n simulations (a,b,c) had lincs issues (maybe on ranks x,y,z). That doesn't provide any guarantees that the message gets handled and output made before the runtime dies from a process segfaulting, but in general there's no promise that the MPI runtime will have propagated the existing terminal messages, either.

Also available in: Atom PDF