-
Notifications
You must be signed in to change notification settings - Fork 112
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 new possiblities for providing paramters. #1756
base: master
Are you sure you want to change the base?
Conversation
Hello @pat-schmitt! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:
|
I managed to fix all tests, beside of Beside of this, the PR slowly gets into a merge-able state. However, as this touches almost all sensitive parts of OGGM, before merging we should have a meeting. I would like to discus if the way I implemented everything is a good way or if their are better ways of doing it. And we need to decide how all this is or could change the default way of handling the params in OGGM. |
This PR introduces two new ways to define and provide parameters for the model (in addition to the current default of using
cfg.PARAMS
):params.cfg
File: You can now pass a minimalparams.cfg
file tocfg.initialize
. If some parameters are missing in this file, the defaults from the mainparams.cfg
(available here) will be used automatically.run_settings.yml
File, which could contain:params.cfg
run_settings.yml
, it falls back to the current defaults.These additions required significant changes in sensitive parts of the model, particularly for the second point. However, tests appear to be passing. I have also included some tests for
run_settings.yml
. Not every aspect is tested yet, as adding more tests would overly expand the test suite.Points for Discussion
Each function currently opens the
run_settings.yml
file independently, instead of opening it once at the start of a workflow and passing it around. While this approach may slightly reduce performance (dynamic runs are not effected by this), it maintains the flexibility needed for setting up custom workflows.The new
run_settings.yml
works similarly to the existingmb_calib
logic but supports calibration for only a single flowline. For now, I’ve keptmb_calib
for backward compatibility and enforce a selection between the two possibilities to avoid potential confusions. However, we could consider removingmb_calib
in the future.When using
run_settings.yml
, all diagnostics are saved both togdir.add_diagnostics
and therun_settings.yml
file. Maybe one or the other is enough?Potentially the run_settings could be used to save all used parameters in each gdir. This would avoid confusions when a default params.cfg and a 'mini-params.cfg' is used, and make it clear which actual parameter was used. However, it also means that many same numbers are saved up to 200000 times globally, where one time would also be enough...
Tests added/passed
Fully documented
Entry in
whats-new.rst