-
Notifications
You must be signed in to change notification settings - Fork 4
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
Split get_background into 3d and 4d tasks #268
base: develop
Are you sure you want to change the base?
Conversation
src/swell/tasks/get_background.py
Outdated
@@ -27,6 +28,56 @@ | |||
|
|||
class GetBackground(taskBase): | |||
|
|||
def _fetch_all(self, background_prep, r2d2_dict, model_component): |
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.
Perhaps it's not necessary to create a function for holding this? Since it's only used in one place?
src/swell/tasks/prep_background.py
Outdated
@@ -0,0 +1,140 @@ | |||
#!/usr/bin/env python |
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'm not sure this is quite the right design. We ultimately need to map between suites, tasks and questions. If you ask window_type
as a suite question then you can set your (e.g.) hofx suite to use the task GetBackground3d if the answer is 3D, otherwise use GetBackground4d. Then you can determine which questions to ask based on what things GetBackground3d is getting out the config. In this case you would never have PrepBackground in the suite so the code wont know to look here for what is coming out of the config. Further, even if it did it would see, for example, background_frequency
which is something only needed by GetBackground4d. So I think there really needs to be files like:
tasks/get_background3d.py
tasks/get_background4d.py
utilities/get_background.py
You can put your class in utilities if you like. But everything you access from the config needs to be in the codes in tasks. It doesn't matter that there might be duplicate things being taken from the config in each. The issue is that you otherwise break the connection between suites, tasks and task_questions.
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.
Here is the code that builds a list of tasks from the suite file (flow.cylc)
def open_flow(self): |
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.
Once it has a list of tasks it greps all the task code in the tasks directory to see which things in the config will be requests. From there it can ask all those questions and create experiement.yaml
…ckground, formally split get_background into 3d and 4d tasks
This PR has been reworked. See updated description. |
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 this looks great. Thanks for working on it. We can just update the remaining suites if need be and clean up comments. Once we get back on track with swell CI we can get it merged.
@@ -1,3 +1,10 @@ | |||
window_type: | |||
ask_question: True | |||
default_value: 3d |
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.
Is it possible to have a defer_to_model
here?
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 not, but I'm trying to remember why.
@@ -5,7 +5,9 @@ analysis_forecast_window_offset: | |||
- all | |||
prompt: What is the duration from the middle of the window when forecasts start? | |||
tasks: | |||
- GetBackground | |||
- GetBackground{{window_type}} |
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 don't think we have a mechanism to resolve Jinja2 templates in the task questions. We just need to list each 3D, 4D, etc tasks as you've done below.
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.
Alluded to this issue in the description. When swell create
is called, flow.cylc
doesn't yet know what window_type
we're dealing with; it's still in template form. We need a way to match that template to task_questions
. This is the simplest, though imperfect, way to avoid the hassle of regex or other pattern matching codes.
depends: | ||
key: window_type | ||
value: 4D | ||
# depends: |
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.
This can indeed be removed. The question will only be asked if the 4D task is found in the suite after it has been resolved.
Description
UPDATED Nov. 16
This PR splits
get_background
task intoget_background3d
andget_background4d
. It is tested on the hofx suite only.The important ability on display here is a way for suite questions to dictate which tasks are called in that suite's flow.cylc script. In lieu of a "map between suites, tasks and questions", which is a work in progress, we can achieve this dependency with minimal code changes and a bit of config gaming.
window_type
is pulled fromtask_questions
and placed intosuite_questions
instead.{{window_type}}
is a placeholder in theflow.cylc
template where GetBackground is called.tasks/task_questions.yaml
, where tasks are listed underneath a question,GetBackground
is replaced with the placeholder versionGetBackground{{window_type}}
. This is needed forswell create
to grab task questions and populate config parameters. Note the imperfection, not just the ugliness, with this approach. Theexperiment.yaml
file may end up with unneeded parameters, likebackground_frequency
for a 3d run.GetBackground3d
andGetBackground4d
are added to these task lists, where appropriate. This is needed forswell task GetBackground3d ...
and the like.While in concept we are abstracting
window_type
away from the config (get_background
tasks no longer grab this element from config dictionary), it still appears inexperiment.yaml
since it is a question that has an answer.Ultimately a better mapping scheme for suites, tasks, and questions is a necessary precursor for this PR, which attempts to fit a square peg into a round hole.
Dependencies
NA
Impact
NA