Closed Giannis1993 closed 3 years ago
Yeah, I would agree with having the logger as separate class. In that way we can think of an interface that we want to have, e.g. which variables we pass towards it, and then have different logging behaviour by implementing different variants of the logging class. Then it shouldn't be too hard to have loggers that print every iteration, every n
iterations, write to files, etc.
Might also be interesting to use Python's logging
module: https://docs.python.org/3/library/logging.html in one of the loggers. That already has functionalities for writing to files, to screen, setting different levels of output etc.
I looked a bit into Python's logging module that @MaxvdKolk was referring to (see links below):
https://www.youtube.com/watch?v=-ARI4Cz-awo&ab_channel=CoreySchafer https://www.youtube.com/watch?v=jxmzY9soFXg&ab_channel=CoreySchafer
Imo, it makes sense to use them, as they add lots of nice functionalities (e.g. different levels of logging data). Not sure though if (and how) a real-time plotting functionality can be implemented with this logging module though. Any thoughts on that?
Maybe before we start coding, let's think of the purposes first. What is the goal? Is it for debugging, or do users also use it for displaying things like convergence?
And what kind of functionality in terms of plotting do we require?
@aatmdelissen I think both are necessary. I was hoping to handle debugging/warning/error messages and convergence plots with the same class, as both essentially are just printing things on either on the terminal or on figures. Maybe its 2 different things though, not sure.
As for the plotting functionality, I think it should be minimal. So a few things (like g_j
, KKT_res
, Dx
, etc.) wrt iter
. We should allow though for extensions to be plotted as well (e.g. things like a direction index), cuz later on -- when we try different intervening variable combinations -- this might give us further insights on what works and what doesn't.
We can probably keep the code for this small. Something that prints some values every n iteration would be sufficient. Plotting of design vars etc, will become too advanced I think. It also differs a lot depending on the problem to visualise. The logs will mostly always be of interest, even it it is just to see if things converge or not.
For logs I referred to the logging module as that makes it easy to print lines to screen/files/both, while the calls (e.g. logging.info
) stay the same. Regarding the implementation, I would think to use logging.info(message)
vs print(message)
. Then all the logging features are available to modify what we see, or where the lines are written too. The standard print always ends up in stdout
Added the logger class, so I'm closing this issue
This is to discuss how to log the data of the problems we are using. My initial idea is to create a class Logger, initialize it before the main loop, and have it do the necessary prints/plots once per iteration as follows:
Not sure also if the PostProcessor should be separate from the Logger or not! (or if we even need a PostProcessor class)