-
Notifications
You must be signed in to change notification settings - Fork 0
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
Scientific Defaults #5
Conversation
I will introduce test cases for the defaults version module when I add the changes to the realisation configuration |
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.
Few comments. I wonder if we had 1 default config and then 24_2_2_1 for example would just replace values that matter for 100m? Could reduce the amount of config line duplicates, not sure if this limits us at all though
Part of the problem regarding the hierarchical approach that Joel suggests for YAML defaults is that I am not sure what variables are dependent on the resolution and what aren't. So it's hard to know what to override. Secondly, I am a fan of keeping things quite simple for defaults so that you can just pass one file around, and publish just one file in papers to show what the settings for simulations were. |
This PR introduces the new workflow changes for scientific defaults. These defaults are an accumulation of all of the magic numbers I could find in the old workflow codebase. These defaults and read and written to realisations by the workflow stages.
Why These Changes?
The old workflow kept defaults across a number of different files. Some default values, such as those for the high frequency simulations, were recorded in code and not recognised as values with scientific significance for simulations. Consolidating the defaults has three advantages:
Summary of the files involved
The
workflow/default_parameters
directory contains four sets of defaults,24.2.2.1
,24.2.2.2
,24.2.2.4
anddevelop
respectively. The first three represent a closest attempt to copy over the defaults from the old workflow. They should not deviate significantly from the old workflow default values. Thedevelop
defaults are defaults for a 400m simulation designed for testing. Develop defaults are not designed to be used for any real experiments.The
defaults.py
module contains code to load the defaults from a version (valid versions given inDefaultsVersion
). The defaults are loaded by the updated realisations module (not part of this PR).