-
Notifications
You must be signed in to change notification settings - Fork 23
Description
More compound/intensive processes such as partitioning & subspace processing have logic dotted about to print relevant info if _debug is set for debugging purposes. It would be better to replace these with dedicated logging (& then extend the logging over time to cover more logic & include more detail for highly-verbose cases).
I think we should add basic logging before we start optimisation work in earnest because configurable well-placed logging calls will allow us to see clearly the state & location of the code as it runs, & then we e.g. only need to apply a custom handler to keep track of each process set-up by mpi4py if we go with that as a/the solution.
Logging would be good for various other reasons, both towards development & user support:
- we can log info at various levels instead of just a 'debug' level, & get relevant output for those cases;
- more control: we can save logs if appropriate & set where the logs are;
- in general, 'debug' implies something negative (bugs) whereas logs imply something positive (care), so if users see the latter they will have more confidence in
cf-pythonI think.
My opinion is that Python's logging module would be the best tool to use, as it is simple & there can be seamless interfacing with logged info from key imported modules (e.g. ESMPy, NumPy).