-
Notifications
You must be signed in to change notification settings - Fork 168
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
Replace gfs_cyc with an interval #2928
Replace gfs_cyc with an interval #2928
Conversation
More manual testing to come, but ready enough to get eyes on it. |
a532f64
to
f6141f8
Compare
61d05ae
to
1e92c40
Compare
To facilitate longer and more flexible GFS cadences, the `gfs_cyc` variable is replaced with a specified interval. Up front, this is reflected in a change in the arguments for setup_exp to: ``` --interval <n_hours> ``` Where `n_hours` is the interval (in hours) between gfs forecasts. `n_hours` must be a multiple of 6. If 0, no gfs will be run (only gdas; only valid for cycled mode). The default value is 6 (every cycle). In cycled mode, there is an additional argument to control which cycle will be the first gfs cycle: ``` ---sdate_gfs <YYYYMMDDHH> ``` The default if not provided is `--idate` + 6h (first full cycle). As part of this change, some of the validation of the dates has been added. `--edate` has also been made optional and defaults to `--idate` if not provided. During `config.base` template-filling, `INTERVAL_GFS` (renamed from `STEP_GFS`) is defined as `--interval` and `SDATE_GFS as `--sdate_gfs`. Some changes were necessary to the gfs verification (metp) job, as `gfs_cyc` was being used downstream by verif-global. That has been removed, and instead workflow will be responsible for only running metp on the correct cycles. This also removes "do nothing" metp tasks that exit immediately, because only the last GFS cycle in a day would actually process verification. Now, metp has its own cycledef and always runs at 18z, regardless of whether gfs is running at 18z or not. This is simplier than trying to determine the last gfs cycle of a day when it could change from day to day. To facilitate this change, support for the undocumented rocoto dependency tag `taskvalid` is added, as the metp task needs to know whether the cycle has a gfsarch task or not. metp will trigger on gfsarch completing (as before), or gdasarch completing if there is no gfsarch. metp tasks are no longer generated for forecast-only, as the pgbanl files (copied of the 1p00 pgbanl files) are not generated for f-o anyway. If metp is needed for f-o, additional work will be needed. Additionally, a couple EE2 issues with the metp job are resolved (even though it is not run in ops): - verif-global update replaced `$CDUMP` with `$RUN` - `$DATAROOT` is no longer redefined in the metp job Depends on NOAA-EMC/EMC_verif-global#137 Resolves NOAA-EMC#260 Refs NOAA-EMC#1299
To avoid running metp on days where there is no gfs, the cycledefs are adjusted somewhat. First, if the interval is >= 24h, the metp cycledef will be identical to gfs. If the interval is < 24h, it remains 18z every day (except the last). Second, a last_gfs is added so metp will run on for the last gfs cycle even if it there is no gdas cycle for 18z that day. This required computing the real gfs end date to use as the last cycle.
18f9752
to
bfc2907
Compare
Ready for review. Also encourage third-party testing in excess of what CI will cover due to the nature of the change. I ran some different multi-day experiments myself, but outside validation would be appreciated. |
Failed because restarts from previous attempt weren't wiped, so forecast picked up in the middle. |
|
Automated global-workflow Testing Results:
|
bd7ed27
to
2c8dace
Compare
All manual CI tests passed on WCOSS:
|
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.
Thanks for all the work on this @WalterKolczynski-NOAA!
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.
Looks good, thanks @WalterKolczynski-NOAA !
|
||
date2 = sdate_gfs + interval_gfs | ||
if date2 <= edate_gfs: | ||
date2_gfs_str = date2_gfs.strftime("%Y%m%d%H%M") |
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.
Just noticed that date2_gfs
should be date2
. I'll fix this in #2943.
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 surprised PEP8 didn't complain about this.
To facilitate longer and more flexible GFS cadences, the `gfs_cyc` variable is replaced with a specified interval. Up front, this is reflected in a change in the arguments for setup_exp to: ``` --interval <n_hours> ``` Where `n_hours` is the interval (in hours) between gfs forecasts. `n_hours` must be a multiple of 6. If 0, no gfs will be run (only gdas; only valid for cycled mode). The default value is 6 (every cycle). (This is a change from current behavior of 24.) In cycled mode, there is an additional argument to control which cycle will be the first gfs cycle: ``` --sdate_gfs <YYYYMMDDHH> ``` The default if not provided is `--idate` + 6h (first full cycle). This is the same as current behavior when `gfs_cyc` is 6, but may vary from current behavior for other cadences. As part of this change, some of the validation of the dates has been added. `--edate` has also been made optional and defaults to `--idate` if not provided. During `config.base` template-filling, `INTERVAL_GFS` (renamed from `STEP_GFS`) is defined as `--interval` and `SDATE_GFS as `--sdate_gfs`. Some changes were necessary to the gfs verification (metp) job, as `gfs_cyc` was being used downstream by verif-global. That has been removed, and instead workflow will be responsible for only running metp on the correct cycles. This also removes "do nothing" metp tasks that exit immediately, because only the last GFS cycle in a day would actually process verification. Now, metp has its own cycledef and will (a) always runs at 18z, regardless of whether gfs is running at 18z or not, if the interval is less than 24h; (b) use the same cycledef as gfs if the interval is 24h or greater. This is simpler than trying to determine the last gfs cycle of a day when it could change from day to day. To facilitate this change, support for the undocumented rocoto dependency tag `taskvalid` is added, as the metp task needs to know whether the cycle has a gfsarch task or not. metp will trigger on gfsarch completing (as before), or look backwards for the last gfsarch to exist. Additionally, a couple EE2 issues with the metp job are resolved (even though it is not run in ops): - verif-global update replaced `$CDUMP` with `$RUN` - `$DATAROOT` is no longer redefined in the metp job Also corrects some dependency issues with the extractvars job for replay and the replay CI test. Depends on NOAA-EMC/EMC_verif-global#137 Resolves NOAA-EMC#260 Refs NOAA-EMC#1299 --------- Co-authored-by: David Huber <[email protected]>
<!-- *** PLEASE READ *** Any PRs not following this template will be closed. Please delete all these comments before submitting the PR. Please use a short (<60 char), descriptive title for the PR title above. It should complete the sentence "If merged, this PR will _____". Capitalize the first word and do not end with a period. No content should appear above the "Description" header. If this PR is not merge-ready (e.g. it depends on other PRs not yet merged), please mark it as draft until it is ready. PRs should meet these guidelines: - Each PR should address ONE topic and have an associated issue. - No hard-coded paths or personal directories. - No temporary or backup files should be committed (including logs). - Any code that you disabled by being commented out should be removed or reenabled. --> # Description <!-- This description will become the commit message for the PR. --> <!-- Solely pointing to an issue is not an adequate description! Please use this format for your description: Describe your changes. Focus on the *what* and *why*. The *how* will be evident from the changes. In particular, be sure to note any interface changes, such as command line syntax, that will need to be communicated to users. At the end of your description, please be sure to add the issue this PR solves using the word "Resolves". If there are any issues that are related but not yet resolved (including in other repos), you may use "Refs". Resolves #1234 Refs #4321 Refs NOAA-EMC/repo#5678 --> This PR brings recent changes from the develop branch to the GEFS reforecast branch. This PR updates the GEFS reforecast branch to develop hash ac3cde5 (10/11/2024). This version of global-workflow uses the ufs-weather-model hash [6a4e09e](https://github.com/ufs-community/ufs-weather-model/tree/6a4e09e94773ffa39ce7ab6a54a885efada91f21) (9/9/2024). Furthermore, this PR ensures the following adjustments for the reforecast: - [x] Speed up rocoto by grouping post job - [x] Optimize PE configuration - [x] Remove duplicate OCNSPPT and EPBL settings - [x] Set restart_interval to fhmax - [x] Turn off SHUM in config.efcs - [x] Set FHMIN_WAV to 3 in config.base - [x] Turn off ATM history file output - [x] Change HMS=${cyc}0000 to HMS=030000 in Wavepostpnt script (#2788) - [x] Include YYYYMMDDHH (PDY) in job name - [x] Change CA seed based on case and cyc for control member and perturbed members - [x] Fix post ensemble info - [x] Add tob to ocean products (#2995 ) - [x] Move PEVPR from b group to a group for atmos products (#2995) - [x] Add option to download initial condition from HPSS - [x] Add ability to download and stage replay analysis from AWS, which is needed for the repair_replay task - [x] Add capability to run forecasts in 7-day intervals (#2928) - [x] Update defaults.yaml so that many of the reforecast-specific settings can be used by default <!-- For more on writing good commit messages, see https://cbea.ms/git-commit/ --> # Type of change - [ ] Bug fix (fixes something broken) - [ ] New feature (adds functionality) - [x] Maintenance (code refactor, clean-up, new CI test, etc.) # Change characteristics <!-- Choose YES or NO from each of the following and delete the other --> - Is this a breaking change (a change in existing functionality)? NO - Does this change require a documentation update? NO - Does this change require an update to any of the following submodules? NO - [ ] EMC verif-global <!-- NOAA-EMC/EMC_verif-global#1234 --> - [ ] GDAS <!-- NOAA-EMC/GDASApp#1234 --> - [ ] GFS-utils <!-- NOAA-EMC/gfs-utils#1234 --> - [ ] GSI <!-- NOAA-EMC/GSI#1234 --> - [ ] GSI-monitor <!-- NOAA-EMC/GSI-Monitor#1234 --> - [ ] GSI-utils <!-- NOAA-EMC/GSI-Utils#1234 --> - [ ] UFS-utils <!-- ufs-community/UFS_UTILS#1234 --> - [ ] UFS-weather-model <!-- ufs-community/ufs-weather-model#1234 --> - [ ] wxflow <!-- NOAA-EMC/wxflow#1234 --> # How has this been tested? <!-- Please list any test you conducted, including the machine. Example: - Clone and build on WCOSS - Cycled test on Orion - Forecast-only on Hera --> This branch is being tested on WCOSS2. When testing has succeeded, this PR will be marked as ready for review. # Checklist - [ ] Any dependent changes have been merged and published - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have documented my code, including function, input, and output descriptions - [ ] My changes generate no new warnings - [ ] New and existing tests pass with my changes - [ ] This change is covered by an existing CI test or a new one has been added - [ ] I have made corresponding changes to the system documentation if necessary --------- Co-authored-by: Wei Huang <[email protected]> Co-authored-by: Kate Friedman <[email protected]> Co-authored-by: Cory Martin <[email protected]> Co-authored-by: Andrew.Tangborn <[email protected]> Co-authored-by: Walter Kolczynski - NOAA <[email protected]> Co-authored-by: AndrewEichmann-NOAA <[email protected]> Co-authored-by: DavidBurrows-NCO <[email protected]> Co-authored-by: AnningCheng-NOAA <[email protected]> Co-authored-by: David Huber <[email protected]> Co-authored-by: Rahul Mahajan <[email protected]> Co-authored-by: AntonMFernando-NOAA <[email protected]> Co-authored-by: BoCui-NOAA <[email protected]> Co-authored-by: DavidNew-NOAA <[email protected]> Co-authored-by: Jeffrey Whitaker <[email protected]> Co-authored-by: mingshichen-noaa <[email protected]> Co-authored-by: Jiarui Dong <[email protected]> Co-authored-by: David Huber <[email protected]> Co-authored-by: Guillaume Vernieres <[email protected]> Co-authored-by: RussTreadon-NOAA <[email protected]> Co-authored-by: Innocent Souopgui <[email protected]> Co-authored-by: Neil Barton <[email protected]>
Description
To facilitate longer and more flexible GFS cadences, the
gfs_cyc
variable is replaced with a specified interval. Up front, this isreflected in a change in the arguments for setup_exp to:
Where
n_hours
is the interval (in hours) between gfs forecasts.n_hours
must be a multiple of 6. If 0, no gfs will be run (onlygdas; only valid for cycled mode). The default value is 6 (every cycle). (This is a change from current behavior of 24.)
In cycled mode, there is an additional argument to control which cycle will be the first gfs cycle:
The default if not provided is
--idate
+ 6h (first full cycle). This is the same as current behavior whengfs_cyc
is 6, but may vary from current behavior for other cadences.As part of this change, some of the validation of the dates has been added.
--edate
has also been made optional and defaults to--idate
if not provided.During
config.base
template-filling,INTERVAL_GFS
(renamed fromSTEP_GFS
) is defined as--interval
andSDATE_GFS as
--sdate_gfs`.Some changes were necessary to the gfs verification (metp) job, as
gfs_cyc
was being used downstream by verif-global. That has been removed, and instead workflow will be responsible for only running metp on the correct cycles. This also removes "do nothing" metp tasks that exit immediately, because only the last GFS cycle in a day would actually process verification.Now, metp has its own cycledef and will (a) always runs at 18z, regardless of whether gfs is running at 18z or not, if the interval is less than 24h; (b) use the same cycledef as gfs if the interval is 24h or greater. This is simpler than trying to determine the last gfs cycle of a day when it could change from day to day. To facilitate this change, support for the
undocumented rocoto dependency tag
taskvalid
is added, as the metp task needs to know whether the cycle has a gfsarch task or not. metp will trigger on gfsarch completing (as before), or look backwards for the last gfsarch to exist.Additionally, a couple EE2 issues with the metp job are resolved (even though it is not run in ops):
$CDUMP
with$RUN
$DATAROOT
is no longer redefined in the metp jobDepends on NOAA-EMC/EMC_verif-global#137
Resolves #260
Refs #1299
Type of change
Change characteristics
How has this been tested?
Checklist