-
Notifications
You must be signed in to change notification settings - Fork 40
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
remove global_params #452
remove global_params #452
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v4-prep #452 +/- ##
===========================================
- Coverage 79.56% 79.25% -0.32%
===========================================
Files 24 23 -1
Lines 3803 3735 -68
Branches 647 638 -9
===========================================
- Hits 3026 2960 -66
- Misses 558 560 +2
+ Partials 219 215 -4 ☔ View full report in Codecov by Sentry. |
A few notes here:
Paths and memory allocation factors were moved into the config, and the config file (along with its warnings) are gone, substituted by a single instance which automatically passes necessary information to the backend via a new very small struct |
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.
@daviesje thanks, this is super nice. I think I agree with everything you've done here. I would say that the config class has actually become almost unnecessary now, so maybe we should htink about whether it is still reuqired (or whether it should only be kept around for these lingering globals).
Also, I'm not sure I totally agree with all the places you're putting parameters. But I could be convinced. In my head, AstroParams
are for actual physical parameters that can be constrained, while FlagOptions
are for discrete options (True/False or choices from a list). This leaves no actual place for options that are continuous, but not a physical parameter (e.g. MAX_DVDR). So I'm not sure what the best place for those are. We should perhaps chat about this.
"direc": Path("~/21cmFAST-cache").expanduser(), | ||
"regenerate": False, | ||
"write": True, | ||
"cache_param_sigfigs": 6, | ||
"cache_redshift_sigfigs": 4, | ||
"ignore_R_BUBBLE_MAX_error": False, |
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 actually don't think any of these settings are being used any more :/ We probably should be using the sigfigs -- we shouldn't lose that functionality. But I don't think the new output struct framework actually accesses this info any more.
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 can remove these as necessary, but I think it's a good idea to have some place we can put variables which don't affect the run output, and may need to be passed in.
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.
Yeah, I think having this structure around makes sense. I think for this PR, let's leave everything in there. Once we merge the output struct PR, we'll have a better sense of what is still required.
As for the placement of the globals, I only considered whether they are utilised before or after the PerturbField finishes. Since we tie the parameter sets to these structs I thought it was more important to use that distinction, even if categorically they make less sense. We can talk about alternate ways to organise the parameters. |
Yeah, the before/after PerturbedField is obviously a very important distinction. |
More notes:
|
) | ||
) + ")" | ||
|
||
|
||
# TODO: force config to be a singleton |
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.
An easy way to achieve some of this is just to make Config
semi-private... i.e. _Config
. It actually doesn't matter if someone creates a new instance of _Config
-- it'll just never be used.
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.
validator=[ | ||
validators.in_(_filter_options), | ||
validators.not_(validators.in_("sharp-k")), | ||
], # TODO: seems bad |
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.
alternatively,
validator = validators.in_([x for x in _filter_options if x!='sharp-k'])
@@ -36,14 +36,5 @@ def test_config_write(cfgdir): | |||
with open(cfgdir / "config.yml", "w") as fl: | |||
yaml.dump(new_config, fl) | |||
|
|||
with pytest.warns(UserWarning): | |||
with pytest.raises(ConfigurationError): |
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 we should just get rid of all config abilities to load/write files.
Note to move some of the AstroParams which we won't want to infer into FlagOptions for a future renaming |
I'm setting up a draft PR for removing the global parameter structure, as many of these are under/unused.
For now I've removed the parameters which were completely unused and I've commented on the others with suggestions of what to do with them.
I will begin to go through the parameters and move/delete them as necessary.