[FEATURE] Logger from the core exposed to users

[mgovers]

The PGM contains many details that may affect the end result for which it would be useful if the user would get some more fine-grained information. Some examples:

• Performance benchmarking.
• Many possible reasons may introduce a sparse matrix error.
  • Logging may provide some hints (nothing conclusive!!!) as to which things may contribute to a sparse matrix.
  • However, we only should do so on request of the user, as it may be part of the hot-loop and comes at a performance cost, so it should be opt-in.

Examples of things that MAY contribute to sparse matrix errors:

• Necessary and sufficient observability check
  • The fact that voltage phasor sensors are not yet included in meshed grid observability checks can provide a hint as to why a sparse matrix error occurs (maybe unobservable, but unknown for sure)
• Floating grids in asymmetric calculations
  • A component may have contribution to the matrix equation that USUALLY is a non-sparse matrix. However, there may be edge cases in which it is known to contribute e.g. a row/column of zeros. (e.g.: a transformer with non-grounding winding type in asymmetric calculations). We can provide that as a hint to the user.
  • Another component may provide a contribution that still makes the total matrix non-sparse. (e.g. a grounding transformer). We can provide that as a hint to the user as well.

None of these things are conclusive: they just provide hints for debugging for advanced users (including ourselves).

Design Proposal

• C++ core
  • benchmark logger is mostly already in place (requires more testing)
  • text logger needs to be added
• C API updates:
  • Add logger types (use multi-threaded versions!!!)
  • Add an enum per logger type, so that we do not have to add a lot of extra functions for each logger
  • Add a vector of logger pointers to the handle object
  • Add functionality to register + unregister the logger to the handle
    • This ensures that logging is opt-in and that multiple types of logging are available (in the sense that one can both register a benchmark logger and a text logger) and also ensures future compatibility
    • Registering a logger multiple times to the same logger is UB (to prevent multiple unregistering)
    • Just like when using handles, using the same logger in multiple user-threads at the same time is UB (core-threads for batch calculations should be OK)
  • Add functionality to create + destroy the logger + retrieve the output
  • Calling unsupported functionality for a specific logger is no-op.
    • This ensures that we can do things like create a DoNothingLogger, which is a valid logger but that doesn't do anything
• Python API:
  • Create + load loggers
  • Get the output
  • Add logger options to the most important objects (like the PowerGridModel class)

[figueroa1395]

Let's also use this issue for more brainstorming from the developers, but also the users, as to what kind of messages or logging information would be useful for them.