search

NOAA-EMC / global-workflow

Global Superstructure/Workflow supporting the Global Forecast System (GFS)
https://global-workflow.readthedocs.io/en/latest
GNU Lesser General Public License v3.0
70 stars 162 forks source link

Add C384mx025_3DVarAOWCDA yamls #2625

Closed JessicaMeixner-NOAA closed 1 month ago

JessicaMeixner-NOAA commented 1 month ago

Description

As additional experiments are starting for GFSv17, this adds the C384mx025_3DVarAOWCDA yaml files for one experiment into a new GFSv17 folder.

To run this test: 

source ../global-workflow/workflow/gw_setup.sh
pslot=t02 RUNTESTS=`pwd` HPC_ACCOUNT=marine-cpu ./../global-workflow/workflow/create_experiment.py --yaml ../global-workflow/ci/cases/gfsv17/C384mx025_3DVarAOWCDA.yaml

HPSS_ACCOUNT and other potentially user defined configs will need to be manually updated still.

Type of change

Change characteristics

How has this been tested?

Not in this exact form. Will need to do a test, but first wanted to get feedback.

Checklist

JessicaMeixner-NOAA commented 1 month ago

@aerorahul this is a draft PR because @guillaumevernieres @CatherineThomas-NOAA and I would like to get your feedback on general formats, etc. Once we're happy with the overall structures, I'll make a test to confirm things are working. The test itself should work (after updates to archive) without issue, this would just be to confirm it works when pointing to new directory structures etc.

JessicaMeixner-NOAA commented 1 month ago

@aerorahul @guillaumevernieres @CatherineThomas-NOAA I've marked this as ready to review after adding a few settings to better reflect what should be on and made a few things more generic (ie not hard-coding account). I've added to the PR description how this test can be run, and am curious if adding that to a readme in the gfsv17 folder would be a good idea? Or if there's another place to add this somewhere else?

This is what I'm thinking to add to a readme: 

source ../global-workflow/workflow/gw_setup.sh
pslot=t02 RUNTESTS=`pwd` HPC_ACCOUNT=marine-cpu HPSS_PROJECT=emc-climate ./../global-workflow/workflow/create_experiment.py --yaml ../global-workflow/ci/cases/gfsv17/C384mx025_3DVarAOWCDA.yaml
aerorahul commented 1 month ago

@aerorahul @guillaumevernieres @CatherineThomas-NOAA I've marked this as ready to review after adding a few settings to better reflect what should be on and made a few things more generic (ie not hard-coding account). I've added to the PR description how this test can be run, and am curious if adding that to a readme in the gfsv17 folder would be a good idea? Or if there's another place to add this somewhere else?

This is what I'm thinking to add to a readme:

source ../global-workflow/workflow/gw_setup.sh
pslot=t02 RUNTESTS=`pwd` HPC_ACCOUNT=marine-cpu HPSS_PROJECT=emc-climate ./../global-workflow/workflow/create_experiment.py --yaml ../global-workflow/ci/cases/gfsv17/C384mx025_3DVarAOWCDA.yaml

This has a potential to cause confusion and is also not the recommended way to create the experiment. The experiment should be created from within the global-workflow and all paths should be relative to HOMEgfs or RUNTESTS

source workflow/gw_setup.sh
pslot=t02 RUNTESTS="/path/to/RUNTESTS" HPC_ACCOUNT="your_allocation" workflow/create_experiment.py --yaml ci/cases/gfsv17/C384mx025_3DVarAOWCDA.yaml
JessicaMeixner-NOAA commented 1 month ago

@aerorahul how is someone supposed to change the HPSS account? Not all of us have write permissions to the default location. I have added runtests to provide more consistency with other tests.

aerorahul commented 1 month ago

@aerorahul how is someone supposed to change the HPSS account? Not all of us have write permissions to the default location. I have added runtests to provide more consistency with other tests.

A flexible configuration system is desired.
Unfortunately, we don't have the time or space to design and implement one. For now, manually edit.

aerorahul commented 1 month ago

@aerorahul how is someone supposed to change the HPSS account? Not all of us have write permissions to the default location. I have added runtests to provide more consistency with other tests.

A flexible configuration system is desired. Unfortunately, we don't have the time or space to design and implement one. For now, manually edit.

The yaml can be edited by the user. The only items that we are currently supporting from the command-line for create_experiment.py are: RUNTESTS HPC_ACCOUNT ICSDIR -- This will go away once stage_ic is refactored.

The rest, should be in the yaml. The yaml should be built by the user, with their specifications. If there is a need to provide another input to the yaml e.g. HPSS_ACCOUNT=.., then it defeats the purpose of the yaml.

JessicaMeixner-NOAA commented 1 month ago

I will say that as a user, having the ability to change HPSS_ACCOUNT, STMP, etc in the yaml file and not having to manually edit things has been a huge help, but have kept things to be as consistent as possible with the ci/pr yaml cases. Hopefully we are now there.

aerorahul commented 1 month ago

I will say that as a user, having the ability to change HPSS_ACCOUNT, STMP, etc in the yaml file and not having to manually edit things has been a huge help, but have kept things to be as consistent as possible with the ci/pr yaml cases. Hopefully we are now there.

I understand and I agree. The yaml file is what the user should be editing so that the config files can be templated and are resolved during create_experiment.py. If the yaml is also excessively templated, then we are just moving the customization problem upstream. In that case, the command line arguments will expand and become longer and longer. For e.g.

pslot="expt_name" RUNTESTS="path_to_RUNTESTS" HPC_ACCOUNT="your_account" HPSS_ACCOUNT="your_hpss_account" STMP="your_choice_of_STMP" PTMP="your_choice_of_PTMP" SOME_VAR1="my_choice_for_VAR1" SOME_VAR2="my_choice_for_VAR2" ... and so on ... ./create_experiment.py --yaml "partially_customised_yaml_but_use_some_var_from_command_line"

There is no need for the yaml file if we can fill everything we need from the yaml into the command-line.

I hope this explains why expanding the options to the command-line is a slippery slope. The yaml provided here is user customizable.

Having said that, we have some idea on how to provide more power to the user by including a user.yaml in the yaml that can circumvent the issue and provide a path for reproducible as well as customizable configurations.

JessicaMeixner-NOAA commented 1 month ago

A user.yaml sounds like a great idea in the future @aerorahul ! The yaml files have been a big help and I understand the balance between command line, yaml, etc is a delicate balance. Thanks for taking the time to explain.