trixi-framework / trixi-framework/Trixi.jl
Implement logging mechanism
- Dominant language
- Julia
- Stars
- 731
- Forks
- 166
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 25
Description
In GitLab by @sloede on Mar 14, 2020, 12:25
Store all regular output plus additional debug information in a log file such
that it can be recovered later, e.g., in `out/trixi_YYYMMDDHHmmss.log`
The logging mechanism of Julia (https://docs.julialang.org/en/v1/stdlib/Logging/) should be used. The idea is the following (roughly as discussed with Gregor):
* All output to console or log files actually goes through logging infrastructure
* We use only two standard log levels, i.e., `@info` and `@debug`
* `@info` is the normal runtime output
* `@debug` is additional output that can help with debugging
* By default, `@info` goes to `stdout` while `@debug` is not evaluated at all.
* If `log=True` or `log=` is provided to `run()`, all `@info` messages go *additionally* to `out/trixi.log` or `out/.log`
* If `debug=True` is provided to `run()` (or `ENV["JULIA_DEBUG"]` is set appropriately), all `@debug` messages are shown at `stdout` as well. In combination with `log=True/`, however, debug messages will *only* be shown in the log file.
It might be interesting to enable other default output if logging-to-file is enabled, e.g., to copy the parameters file used to the beginning of the log file, or some information on when and where and with which command line arguments trixi was started.
Potential use cases where it might be interesting to have a permanent log:
* AMR: current number of elements; elements added/removed; number of elements at each level
* shock capturing: information about minimum/maximum alpha values; number of pure DG/blended DG-FV elements
Contributor guide
Assessment
This issue has not been assessed yet.