Agree on standards for different types of output and log files
If the user explicitly request verbosity it is not reasonable to not print detection output. Without that task assignment output makes very little sense. It is also diagnostic output that has previously been printed and unless I missed it there has been no consensus on removing it, nor convincing amount of user feedback that its it not wanted (i.e. nobody complained).
#3 Updated by Erik Lindahl about 1 month ago
NB: Several of US have complained that there is FAR too much irrelevant diagnostic information printed to stderr.
The usual reason for the verbose flag is that the user wants to see an interactive update how the simulation is proceeding (i.e., the stepcounter), not that all diagnostic information should be on stderr. In particular, we most definitely do not have any rule that we print everything until users complain.
#6 Updated by Mark Abraham about 1 month ago
In the short term, I don't think hardware or parallelism report or summary should ever go to a terminal output file, because that's content that isn't useful without all the other things that are present in a log file.
In the medium term (e.g. to discuss with gmx-developers and then users after release), I think it makes sense to do something like
- to stderr: nothing except information about an actionable error
- to stdout: 1-2 lines (first line: gmx mdrun, detailed version number, maybe 20 chars of running on x nodes, y ranks and z gpus; second line: Simulation completed/halted because of -maxh/SIGTERM/etc. after x elapsed time, rate y ns/day); if stdout is a TTY then output the progress meter before replacing it with the 2nd line (any alternatives?)
- to log file: roughly as now, full hardware and version report, warnings, notes, errors, nstlog output, note upon steps when checkpointing, note about why we are stopping when we stop, performance summary with pointer to the perf log, truncation upon appending as now
- to perf log file: full hardware and version report, lots of breakdown about what is going on and why, no pressure to limit the number of lines, no cryptic '!' symbols to suggest maybe there's an issue (do we even document anything about that with DLB?), full performance report, no need to truncate upon appending
gmx mdrun -h etc. writes to stdout because the user asked for the help. Usage descriptions that help the user understand why
gmx mdrun -defnm doesn't work go to stderr.
gmx mdrun -quiet goes away because that's now the default-and-only option (but we don't give an error if some old script still uses it)
I don't have a vision for what would be useful for users in
gmx mdrun -v, but I think it should be something that they couldn't get by reading the normal log file online/later.
I could buy
gmx mdrun -v having additional behaviour if GMX_DEVELOPER_BUILD was on, but I think there is value in us dog-fooding our code the same way we expect users to use it (e.g. read the log file(s)).
Useful background thoughts: https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
#9 Updated by Berk Hess about 1 month ago
I agree with Szilard that we should not be printed task assignments etc to stderr when we have not printed how many cores we have and what GPUs the GPU id's refer to. We should either print a complete, intelligible picture or print nothing.
On a more general note, I don't think a beta phase is the right time to remove lots of output from stderr and log. We should discuss our strategy here more broadly, and especially with a wider range of user types before makes such user facing decisions.
#10 Updated by Erik Lindahl about 1 month ago
- Tracker changed from Bug to Task
- Subject changed from mdrun verbose output is missing hardware summary to Agree on standards for different types of output and log files
- Target version set to 2019
- Affected version deleted (
I don't think anybody is arguing that we need to remove more stuff. The original changes Szilard refers to were uploaded in the beginning of november and went in well before beta1.
I agree that we should keep the rest of the discussion for 2019, and have changed topic accordingly.
Maybe a better way to think about it (to avoid flooding stdout) is to decide that each module/functionality (e.g. hardware assignment or domain decomposition) can use one line of output to stdout for notes, and another one for warnings - and then it is up to each module what information to prioritise.