artofscience / SAOR

Sequential Approximate Optimization Repository
GNU General Public License v3.0
5 stars 1 forks source link

Logger #4

Closed Giannis1993 closed 3 years ago

Giannis1993 commented 3 years ago

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:

logger = Logger(...)

while not converged
    g = response(x)
    dg = sensitivity(x)
    log(...)        # here either print on the console, or plot

    approx.build_approx(...)
    x_new = solver.sub_solve(...)
    itte += 1
    approx.update_old_values(...)
    criterion.assess_convergence(...)
    x = x_new

Not sure also if the PostProcessor should be separate from the Logger or not! (or if we even need a PostProcessor class)

MaxvdKolk commented 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.

Giannis1993 commented 3 years ago

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?

aatmdelissen commented 3 years ago

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?

Giannis1993 commented 3 years ago

@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.

MaxvdKolk commented 3 years ago

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

Giannis1993 commented 3 years ago

Added the logger class, so I'm closing this issue