-
Notifications
You must be signed in to change notification settings - Fork 176
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
Correct diagnostic file handling in ush/ozn_xtrct.sh #1004
Labels
bug
Something isn't working
Comments
I'll fix this if I can be assigned to it. |
EdwardSafford-NOAA
added a commit
to EdwardSafford-NOAA/global-workflow
that referenced
this issue
Aug 30, 2022
work in progress
EdwardSafford-NOAA
added a commit
to EdwardSafford-NOAA/global-workflow
that referenced
this issue
Sep 7, 2022
Merge branch 'develop' into feature/fix_1004
4 tasks
EdwardSafford-NOAA
added a commit
to EdwardSafford-NOAA/global-workflow
that referenced
this issue
Sep 7, 2022
Use braces on all script vars.
WalterKolczynski-NOAA
pushed a commit
that referenced
this issue
Sep 7, 2022
The OznMon's ush/ozn_xtrct.sh script creates a list of available sat/instrument sources for a given cycle in order to report missing files. The logic for extracting the list of sources worked on wcoss2 and hera but failed on orion. The logic used a listing of the diagnostic files which included user name. That created a parsing problem if the user name was not the expected length. The solution is to simply do a single line listing (ls -1) and parse the results. Additionally the processing logic was condensed and now avoids running the extraction executables in the case of a missing diag file. Fixes #1004
WalterKolczynski-NOAA
added a commit
to WalterKolczynski-NOAA/global-workflow
that referenced
this issue
Oct 17, 2022
Splits the existing rocoto cycle definitions up to offer better job control. This means that only the jobs that are due to run will appear in a cycle's job list from rocotostat/rocotoviewer. It also allows for the removal of some of the cycleexist dependencies that were there solely to prevent the job from running in the half cycle. A side effect of this change is that the half-cycle will be recognized as a completed cycle, fixing the bug with archive jobs starting in the fourth cycle (NOAA-EMC#1004). The gdas cycledef has been split into a `gdas_half` for the first half- cycle and `gdas` for the other GDAS cycles. Tasks that run during that first half-cycle therefore run on two cycledefs. For gfs, instead of slicing perpindicular to time, a new cycledef `gfs_cont` (continuity) was created in parallel to the existing gfs cycledef that omits the first cycle. This was done since only one job (`aerosol_init`) currently skips the first cycle, and this prevents the need to provide two cycledefs for every gfs task but one. Since some time math is now being done on sdate in workflow_xml.py, we now keep those as datetime objects and only convert to string when writing the cycledef strings. In order to access the pygw utilities in the workflow directory, a symlink is created in `workflow` pointing to the pygw location in `ush`. A better solution may be found in the future. Fixes NOAA-EMC#1003
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Testing for PR #674 revealed a problem in ush/ozn_xtrct.sh.
Expected behavior
vrfy should run without error.
Current behavior
Diagnostic file names in the oznstat file are not being parsed correctly. The filename parsing logic is insufficiently robust and fails on orion only. The problem manifests when the oznmon_time.x executable attempts to open a diagnostic file that doesn't exist, causing the executable to halt. This is reported in the gdasvrfy.log.
Machines affected
Orion
In addition to fixing the file parsing, a check will be added to verify the diagnostic file exists and, if it doesn't, avoid running the executable.
The text was updated successfully, but these errors were encountered: