Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add different levels of logging? #251

Open
shoubhikraj opened this issue Feb 24, 2023 · 1 comment
Open

Add different levels of logging? #251

shoubhikraj opened this issue Feb 24, 2023 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@shoubhikraj
Copy link
Collaborator

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

@t-young31
Copy link
Member

💯 agree. lots of logging.INFO should be logging.DEBUG

when writing a new module I'd be tempted to just use print statements and ditch any stderr. then do a find & replace to logging.DEBUG after

@t-young31 t-young31 added enhancement New feature or request good first issue Good for newcomers labels Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants