One minor issue I am having is that the logging.INFO and logging.WARNING levels are too verbose, they print a lot of information. For example, when you are running an optimisation, it is better to have information about the iterations, but along with that there would be logging.info() entries arising from the autode.calculation or autode.species modules which clutter the log output, so that you have scroll quite a lot to find the successive geometry iterations.
I am wondering if it would make sense to create more levels of logging: So for example use the default warning for more severe runtime warnings that the user needs to really know, and then have default info for actual output (in the way that QM softwares print output) and then create debugwarning for program level warnings (such as a warning when calling new_species() from autode.Species removes the gradient, hessian etc., which end users do not need to see except when debugging, or perhaps when the program assumes the valency of an atom, or the warnings about not setting method string from calculation), and finally, you would have the debug level for very verbose information (such as printing out the array of the mode along which optimiser is stepping etc.)
(It also is a problem during writing a new module, as I have to fiddle with the log levels in the newly created module so that I can see what is going on there, instead of being swamped by logs coming from the other parts of autodE.)
One minor issue I am having is that the
logging.INFO
andlogging.WARNING
levels are too verbose, they print a lot of information. For example, when you are running an optimisation, it is better to have information about the iterations, but along with that there would belogging.info()
entries arising from theautode.calculation
orautode.species
modules which clutter the log output, so that you have scroll quite a lot to find the successive geometry iterations.I am wondering if it would make sense to create more levels of logging: So for example use the default
warning
for more severe runtime warnings that the user needs to really know, and then have defaultinfo
for actual output (in the way that QM softwares print output) and then createdebugwarning
for program level warnings (such as a warning when callingnew_species()
fromautode.Species
removes the gradient, hessian etc., which end users do not need to see except when debugging, or perhaps when the program assumes the valency of an atom, or the warnings about not setting method string from calculation), and finally, you would have thedebug
level for very verbose information (such as printing out the array of the mode along which optimiser is stepping etc.)(It also is a problem during writing a new module, as I have to fiddle with the log levels in the newly created module so that I can see what is going on there, instead of being swamped by logs coming from the other parts of autodE.)