Log at debug level

[georgii-tishenin]

Issue Summary

It is somewhat challenging to configure logging at the debug level. Additionally, there seems to be a mismatch between the intended and actual use of the Logger class.

Example Scenario

I am working with the DP_VS_RL1 example and I want to see the SPDLOG_LOGGER_DEBUG messages in the log files of components and the solver. I have implemented this in the log-at-debug-level branch in my fork.

Steps Taken:

1. Set debug logging level for components and simulation objects in the DP_VS_RL1 example.
   • This step is intuitive.
2. Set SPDLOG_ACTIVE_LEVEL to DEBUG in Logger.h.
   • This step is less intuitive. But I do understand this is necessary to compile out debug logging statements for performance reasons.
3. Set log level for mSLog in TopologicalPowerComp and Solver.
   • This step is not intuitive to me and suggests a mismatch between the intended and actual use of the Logger class by TopologicalPowerComp, Solver, and other classes.

Identified Mismatch

• The Logger class has a static Logger::setLogLevel function to set the log level for a spdlog::logger object, but this function is never used (at least, I couldn't find any references).
• TopologicalPowerComp and Solver call the static Logger::get function to create/get the spdlog::logger object. However, the log level of the spdlog::logger object is not set within the scope of the Logger::get function, resulting in a default log level of info.

Suggestions for Improvement

1. Eliminate the need for Step 3.

   • Either adjust the Logger class or it's usage, so that the log level is set appropriately when creating or retrieving a spdlog::logger object.

2. Address the less intuitive aspects of Step 2:

   • Document the need to set SPDLOG_ACTIVE_LEVEL to DEBUG.
   • Automatically set SPDLOG_ACTIVE_LEVEL to DEBUG for Debug builds.

Discussion
What do you think? I look forward to your feedback and discussion on these points.

[leonardocarreras]

There was an older effort in #236 to improve the logging and have some potential solutions that are relevant to here, and that is also the type of change that somehow solves #239 if we have more than one package