trixi-framework/Trixi.jl

Implement logging mechanism

Open

#4 opened on Aug 18, 2020

View on GitHub
 (8 comments) (0 reactions) (0 assignees)Julia (153 forks)batch import
backlogenhancementgood first issue

Repository metrics

Stars
 (686 stars)
PR merge metrics
 (Avg merge 19d 17h) (36 merged PRs in 30d)

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=<filename> is provided to run(), all @info messages go additionally to out/trixi.log or out/<filename>.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/<filename>, 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