Accelerated RFC to place PlanetiQ RO data in monitor mode #2951
Comments
RussTreadon-NOAA
added
production update
|
Shuffled other current release branches around and recut |
|
@RussTreadon-NOAA sounds like this may or may not happen? Let me know the status when you do. Also, let me know the new GSI tag name when/if created. I will prep release notes and be ready to update the GSI tag in the release branch when/if available. I'll ask you to review a PR into the release branch from my fork once ready. FYI, we will be handing off a new GFS version that is a companion to the |
|
Additional update from @RussTreadon-NOAA in #2591 (#2591 (comment)): Thanks for the update @RussTreadon-NOAA ! Will see what the DA team decides and go from there. |
|
DA team decided to move forward with ARFC to place PlanetiQ gpsro data in monitor mode. This is a one line change to
|
|
GSI branch release/gfsda.v16 at 7aabf37 tagged as gfsda.v16.3.19 |
|
@KateFriedman-NOAA , let me know what you need from me and I'll work to get it to you as quickly as possible. |
@RussTreadon-NOAA please review PR #2952. Once the release branch in the auth repo is ready I can cut a hand-off tag. Who is submitting the CDF? |
|
I'm fine with submitting the ARFC but don't know what has been current practice. How have we been handling the CDF for recent implementations? |
|
@RussTreadon-NOAA Tag cut for CDF: EMC-v16.3.19
The last few upgrades were sudden or upstream so we didn't do CDFs and NCO manually made the new version installs with local edits. The upgrades before that had CDFs...either me or the component POC (e.g. Andrew for a few). I'd do a regular CDF since we're initiating it and choose the "Accelerated change" option. Let me know if I can assist with the CDF. |
|
@KateFriedman-NOAA , I'm touching base with Daryl to see how he would like to proceed since we are in CWD. |
|
As I wait for his reply (he is on travel), I am stepping through the Implementation Instructions in Release_Notes.md on my directory on Cactus. It's been a long time since I built a gfs.v16 package. |
|
Sounds good @RussTreadon-NOAA, thanks! I have to step away from my desk now but will check back periodically. Let me know if you need anything else from me for this stage. I'll take care of the last six checklist items above once this goes into ops. |
|
Thank you @KateFriedman-NOAA . I appreciate your quick action this afternoon. The ball is on my side of the court. I'll keep you in the loop as things progress. |
|
@KateFriedman-NOAA: tag EMC-v16.3.19 has been installed on Cactus in The unexpected diffs are related to WAFS.
The diff in
Does tag EMC-v16.3.19 contain changes from g-w issue #2591? Do we want WAFS changes in tag EMC-v16.3.19? |
|
Also see difference in EMC-v16.3.19 sets |
|
@RussTreadon-NOAA those are all expected differences due to how NCO made those installs with manual local updates.
No, you're seeing the sudden update in ops early last week to adjust the wait time for UKMet data and update an email message in WAFS within the GFS package, resulting in v16.3.18. See https://github.com/NOAA-EMC/global-workflow/releases/tag/gfs.v16.3.18 and NOAA-EMC/WAFS@gfs_wafs.v6.3.2...gfs_wafs.v6.3.3 Good catch, looks like we have an extra line return when we shouldn't though in the EMC WAFS copy but NCO has it correctly so that's what matters. We are going to remove WAFS from the GFS soon but I will fix that extra line return and recut the WAFS tag so if NCO does a full install it's ok.
Our |
|
Thank you @KateFriedman-NOAA. Good to know that EMC-v16.3.19 differences noted above with respect to /lfs/h1/ops/prod/packages/gfs.v16.3.8 can be ignored. |
|
@YaliMao-NOAA FYI I have fixed the email line that Russ noticed during a compare and recut the latest WAFS tag. I did it quickly so the WAFS tag is good in case this ARFC or following implementation pre-WAFS-removal does a full fresh install in ops. Apologies if I overstepped in the WAFS repo. I re-released the latest tag with the fix: https://github.com/NOAA-EMC/WAFS/releases/tag/gfs_wafs.v6.3.3 |
|
WCOSS2 (Cactus) tests Use operational
The analysis results from 1 and 2 are bitwise identical. This is expected because PlanetiQ gpsro data is not in the operational gpsro dump file, The analysis results from 3 and 4 differ. This is expected because PlanetiQ gpsro data is in the test gpsro dump file. whereas
Tagging @XuanliLi-NOAA, @HaixiaLiu-NOAA , and @dtkleist for awareness. |
|
@RussTreadon-NOAA checking in, has the CDF for this ARFC been submitted yet? |
|
Sorry for not notifiying you, @KateFriedman-NOAA . Yes, the ARFC was submitted Tuesday, 9/24/2024, afternoon. NCO reached out to Daryl and me for more information. The ARFC has been assigned to Wei Wei. An implementation date has not yet been set but it could be implemented as early as Monday, 9/30/2024. |
|
Sounds good, no worries, thanks @RussTreadon-NOAA! Please let me know if the implementation date changes, thanks! |
|
@KateFriedman-NOAA , NCO implemented the ARFC for gfs.v16.3.19 just prior to the start of the 20240930 12Z gfs cycle. |
|
Thanks for letting me know @RussTreadon-NOAA ! I will work on the post-implementation tasks to wrap up this issue. Will ask you to review the merge of the release branch for this into the |
|
FYI @KateFriedman-NOAA , NCO implemented gfs.v16.3.19 as a copy of gfs.v16.3.18 with changes to The wall time for and |
|
@RussTreadon-NOAA : For my PIQ experiment, Is it better to git clone and build v16.3.19 once the data flow begins, or is it okay to use v16.3.18? |
|
@XuanliLi-NOAA , gfs.v16.3.18 and gfs.v16.19 only differ in three files That said, if I am running a test with operations as the control I like to use exactly what operations is using apart from the changes I am testing. I would use gfs.v16.3.19. Regarding chgres_cube I see what you are saying. It took a bit of poking around but I think I see what's going on. File Only the cycle and emcsfc builds are turned on. This agrees with what I see in `gfs.v16.3.19/sorc/logs/build_ufs_utils.log |
NCO increased the walltime for the enkfgdas_update job by 5mins (from 30mins to 35mins) Refs NOAA-EMC#2951
|
@RussTreadon-NOAA Thank you for answering my questions. I tried to turn on chgres in the cfg file, but it's looking for ../modulefiles/fv3gfs/global_chgres.wcoss2, which is missing. The available wcoss2 module files are emcsfc_ice_blend, emcsfc_snow2mdl, and global_cycle. |
NCO increased the walltime for the `enkfgdas_update` job by 5mins (from 30mins to 35mins) ahead of implementation today. Refs #2951
|
@XuanliLi-NOAA , we need to contact @GeorgeGayno-NOAA . As you note, gfs.v16.3.19 uses ops-gfsv16.3.0. This branch is quite old. A newer branch may be build Altenatively, you can build |
|
@RussTreadon-NOAA, thank you so much! I'll give it a try with the g-w develop branch. |
The ops-gfsv16.3.0 branch was created only to support the OPS GFS. Since GFS does not use chgres_cube, the build for that program was not updated for WCOSS2.
Yes, use the latest version of ufs_utils as used by the g-w develop branch. |
|
@GeorgeGayno-NOAA, thanks for the information. |
|
This makes sense @GeorgeGayno-NOAA . Implementation packages should only build applications to be used in operations. |
An ARFC in NCEP operations placed PlanetiQ RO data in monitor mode ahead of the 12z cycle on September 30th. A new GSI tag (`gfsda.v16.3.19`) with an updated `global_convinfo.txt` file was provided. The walltime for the `enkfgdas_update` job was also increased from 30 mins to 35 mins. Refs #2951
|
Release branch merged into |
|
FYI: Check of operational gdas gsistat files shows PlanetiQ RO data is flowing through system in monitor mode effective 20241002 12Z |
|
Thanks @RussTreadon-NOAA for confirming that. |
|
From the October 4th RFC memo: |
Description
PlanetiQ data has added noise. This issue issue is opened in case we decide to place this data in monitor mode until we more fully examine it.
Target version
v16.3.19
Expected workflow changes
The only file changed is
global_convinfo.txt. This requires a new GSI tag and a new GFS tag.Tasks
The text was updated successfully, but these errors were encountered: