Ocean_prod task not being triggered when REPLAY_ICS is set to YES #2725
Labels
bug
Something isn't working
Comments
EricSinsky-NOAA
changed the title
This was referenced Jul 8, 2024
WalterKolczynski-NOAA
added a commit
that referenced
this issue
Aug 13, 2024
This PR fixes a couple issues that arise when replay initial conditions are used. These issues only occur when `REPLAY_ICS` is set to `YES` and `OFFSET_START_HOUR` is greater than `0`. The following items are addressed in this PR. 1. Fix issue that causes ocean_prod tasks not to be triggered (issue [#2725](#2725)). A new diag_table was added (called `diag_table_replay`) that is used only when `REPLAY_ICS` is set to `YES`. This diag_table accounts for the offset that occurs when using replay IC's. 2. Fix issue that causes atmos_prod tasks not to be triggered for the first lead time (e.g. f003) (issue [#2754](#2754)). When `OFFSET_START_HOUR` is greater than `0`, the first `fhr` is `${OFFSET_START_HOUR}+(${DELTIM}/3600)`, which is defined in `forecast_predet.sh` and will allow data for the first lead time to be generated. The filename with this lead time will still be labelled with `OFFSET_START_HOUR`. 3. Minor modifications were made to the extractvars task so that atmos data from replay cases can be processed. This PR was split from PR #2680. Refs #2725, #2754 --------- Co-authored-by: Walter Kolczynski - NOAA <[email protected]>
|
This issue has been resolved with the merging of PR #2755. Closing as complete. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is wrong?
When
REPLAY_ICSis set toYES, the ocean_prod tasks are not triggered.What should have happened?
The ocean_prod tasks should run even when
REPLAY_ICSis set toYES.What machines are impacted?
All or N/A
Steps to reproduce
REPLAY_ICStoYESinconfig.base.oceanis one of the components set to run in your experiment.Additional information
This issue is caused by
OFFSET_START_HOURnot being0. This offset causes filename mismatches between the actual raw data being produced by MOM6 and the links produced by the global workflow. This mismatch results in ocean hist files not being saved inCOMROOT, resulting in the ocean_prod task dependencies not being satisfied.Do you have a proposed solution?
A fix has been added in PR #2680. In this fix, a separate diag_table file has been created that is only used when
OFFSET_START_HOURis not0. This diag_table allows the correct filenames to be produced by MOM6 (see image below). In this fix, whenOFFSET_START_HOURis3andFHOUT_OCNis6, the first lead time is averaged from f003 to f009, the second lead time is averaged from f006 to f012, the third lead time is averaged from f012 to f018, and so on.The text was updated successfully, but these errors were encountered: