-
Notifications
You must be signed in to change notification settings - Fork 1
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
Verbosity #305
Verbosity #305
Conversation
…ing with an appropriate level
…change the verbosity level
What about having a command line argument option for setting the verbosity? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works really nicely.
Here are some suggestions for improvements to printing:
- There are
print
statements insrc/WallGo/__init__.py
which are always called, and hence not controlled by the verbosity level. Can these be replaced by logging statements, or does this require the WallGoManager already to be initialised? - There is also a
print
statement insrc/WallGo/PotentialTools/__init__.py
for which I would ask the same question. - There is a
print(self.modelParameters)
statement in the__init__
in yukawa.py which just prints an empty dict. I think this can be just deleted. - There is a space at the beginning of the line printing
=== Begin EOM with off-eq effects ignored ===
which should be removed. WallGoManager.setVerbosity
should have a docs string.
It's already in the wallGoExampleBase file. So when you run an example, you can add something like '--verbose 20' (which would set it to the INFO level). However, this is not in the source code, so it won't be available if a user codes their own example without using ours. |
Yes, to work properly, the logging module must be initialised. Since the init file is the first thing to be called, I don't see how the user could have any control over the verbosity in there. Do you have a solution? |
After a quick look:
The whole logic behind loading WallGoCollision internally could use polish and I'm not sure what the best approach here would be. The main complication is that if we want to allow WallGo to be used without WallGoCollision installed, we can't import eg. collisionHelpers.py into the WallGo package without first checking that WallGoCollision can be successfully imported. |
Okay, thanks for the explanation. I don't think we don't want plain print statements in the |
Lauri raises a good point about the interrelation between WallGo and WallGoCollisions. At the moment there are lots of different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes. I suggest let's remove print statements from __init__
, replacing those that relate to warnings or errors with warnings or errors. And, as Lauri says, the _initializeInternal
in WallGo/__init__.py
doesn't do anything useful anymore so can be removed.
Models/wallGoExampleBase.py
Outdated
"--verbose", | ||
type=int, | ||
default=logging.DEBUG, | ||
help="""Set the verbosity level. Must an int: DEBUG=10, INFO=20, WARNING=30, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Must an int" -> "Must be an int"
I removed the prints in the init file. Let me know if I can merge it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiny change requested (add raise
).
src/WallGo/__init__.py
Outdated
_bCollisionModuleAvailable = True # pylint: disable=invalid-name | ||
|
||
from .collisionHelpers import * | ||
|
||
except ImportError as e: | ||
print(f"Error loading WallGoCollision module: {e}") | ||
print( | ||
RuntimeWarning(f"Error loading WallGoCollision module: {e}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be raise RuntimWarning(...
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it has to be warnings.warn(...)
, otherwise raise
would stop the program.
Added different verbosity levels in the source code using the standard logging module. The user can change the verbosity level with the function WallGoManager.setVerbosity(). The levels follow the standard logging convention, with logging.DEBUG=10, logging.INFO=20, logging.WARNING=30 and logging.ERROR=40.
I wasn't sure if the verbosity level should be treated as another config parameter and included in the config file. In the end I didn't choose to code it like that, but I'm open to another opinion.
Most of the information that was previously shown with print() is now at the INFO level. The detail of the pressure calculation (showing the pressure and error at each iteration) is at the DEBUG level. Every message printed when something not expected happens is at the WARNING level. Let me know if you think some of the levels are not appropriate.