search

UMEP-dev / SuPy

SUEWS that speaks Python
https://supy.readthedocs.io/
GNU General Public License v3.0
13 stars 7 forks source link

improve log file treatment #78

Closed matthiasdemuzere closed 1 year ago

matthiasdemuzere commented 1 year ago

Describe the Issue When running supy, SuPy.log is created in the directory where the simulation is executed.

This seems to be defined in the _env.py module.

Is there no option to set another logpath in the beginning @sunt05 ? Or manipulate its filename? As I'd like to keep a log per simulation I do, sensitivity simulations will likely be done at the same time on the same machine. So a more unique log filename or location would be useful.

Supy version supy.version: 2022.9.22 supy.__version_driver__: 2021a14.post3

Is supy_debug-xxxxxxxx.zip generated? NA

Screenshots NA

Additional context NA

sunt05 commented 1 year ago

Hi @matthiasdemuzere, I had a go for adding some unique identifier to the log filename for every supy session, which seemed to be working. However, if the simulations are initiated in the same supy session. e.g. multiple supy runs done with a for-loop, all logging info would still be dumped into the same log file.

Would that be enough for you?

matthiasdemuzere commented 1 year ago

Hi @sunt05, thanks for this. Having a unique log file per supy session is already a good step forward. But since I plan to launch multiple supy runs directly after each other, I think this will not yet work for me?

But no worries, I can probably also do without having separate log files ...

RussellGl commented 1 year ago

Can I add to this thread as well - Is there a way to have the log files spit out the parameters of the run? Info from the SiteSelect file for example? I have tried changing the debug level to be higher but nothing seems to happen when going from 20 to 10. Thanks a lot.

sunt05 commented 1 year ago

Hi @RussellGl , it seems some clarifications are needed here: 1) log files are mostly to monitor the runtime info: e.g. model speed, diagnostic info regarding the software design, etc.; they are not designed for storing/printing model configurations. 2) for your purpose, df_state is what you might want to look up for such info - ALL model configuration info is stored there.

If you have other questions regarding using df_state, feel free to start a new issue to extend this discussion - thanks!

sunt05 commented 1 year ago

closed as requests have already been dealt with by existing functionalities.