Sync WW3 develop to dev/ufs-weather-model 2026-08-11 (#3318) // Enhance Jenkinsfile with status tracking and error handling (#3324)

[mingchen-NOAA]

Commit Queue Requirements:

• This PR addresses a relevant WM issue (if not, create an issue).
• All subcomponent pull requests (if any) have been reviewed by their code managers.
• Run the full Intel+GNU RT suite (compared to current baselines), preferably on Ursa (Derecho or Hercules are acceptable alternatives). Exceptions: documentation-only PRs, CI-only PRs, etc.
  • Commit log file w/full results from RT suite run (if applicable).
  • Verify that test_changes.list indicates which tests, if any, are changed by this PR. Commit test_changes.list, even if it is empty.
• Transparency in the use of generative AI is required by NOAA policy. Was GenAI used in this work?
  • [Generative AI tool (insert name, if any)] was used to assist with developing this code. The code has been reviewed, edited, and validated by NWS staff.
• Fill out all sections of this template.

---

Description:

#3318

Routine sync of WW3 develop to dev/ufs-weather-model.
WW3 input changes.
No answer changes.

#3324

Added environment variables for status tracking and updated error handling in multiple stages. Enhanced logging and commit messages for ORT results.
Provides information in the commit message about whether the run succeeded or failed and the directories for the regional_control and control_p8 ORT tests. Restructures the code so that bash shells are within groovy commands that capture the error status and convert it to build and stage results -- set to "unstable" if the OpnReqTest failed (yellow exclamation point) -- but the build continues to the next stage. If one test fails, the result is the OpnReqTest fails. Pass or fail, that message is included in the Git Commit message as well as the directories for the tests. The run continues to the end and the labels are removed, preventing a retest.

Commit Message:

* UFSWM - Sync WW3 develop to dev/ufs-weather-model
* UFSWM - Enhance Jenkinsfile with status tracking and error handling
  * WW3 - Sync develop as of 8-11-2026 to dev/ufs-weather-model

Priority:

• Critical Bugfix: Reason
• High: Reason
• Normal

Git Tracking

UFSWM:

• Closes Updating WW3 develop -> dev/ufs-weather-model #3317

Sub component Pull Requests:

• WW3: Sync WW3 develop to dev/ufs-weather-model NOAA-EMC/WW3#1618

UFSWM Blocking Dependencies:

• Blocked by #
• None

Documentation:

• Documentation update required.
  • Relevant updates are included with this PR.
  • A WM issue has been opened to track the need for a documentation update; a person responsible for submitting the update has been assigned to the issue (link issue).
• Documentation update NOT required.
  • Explanation:

---

Changes

Regression Test Changes (Please commit test_changes.list):

• PR Adds New Tests/Baselines.
• PR Updates/Changes Baselines.
• No Baseline Changes.

Input data Changes:

• None.
• PR adds input data.
• PR changes existing input data.

New WW3 input data on Ursa: /scratch4/NCEPDEV/marine/Ming.Chen/ww3/ursa/syncdevelop2ufswm20260805/WW3_input_data_20250807

Library Changes/Upgrades:

• Required
  • Library names w/versions:
  • Git Stack Issue (JCSDA/spack-stack#)
• No Updates

---

Testing Log:

• RDHPCS
  • Orion
  • Hercules
  • GaeaC6
  • Derecho
  • Ursa
• WCOSS2
  • Dogwood/Cactus
  • Acorn
• CI
• opnReqTest (complete task if unnecessary)

Testing Remarks:

[gspetro-NOAA]

@mingchen-NOAA Since the new data changes existing data, do you want me to create a new directory under input-data-20260617, like input-data-20260617/WW3_input_data_20260811, or shall I create a whole new input-data directory (e.g. input-data-20260811)?
Related to that, is there a plan to retire any of the older WW3 input data directories? We have the following directories currently in input-data-20260617

• WW3_input_data_20250114
• WW3_input_data_20250212
• WW3_input_data_20250225
• WW3_input_data_20250807

It would be good to delete these eventually if they are no longer needed. If you'd like to do that now, then I can create a new input-data-20260811 with the new data in it and old dirs removed. Open to other suggestions, too! 🙂

[JessicaMeixner-NOAA]

@gspetro-NOAA the process in the past has always been to just create a new WW3 directory so: input-data-20260617/WW3_input_data_20260811

Depending on how far back you want to maintain backwards compatibility means how many WW3 directories you should keep. I think we kept too many the last time there was a new input-data-YYYYMMDD that was kept. Anytime we create a new input-data-YYYYMMDD we should only keep the last WW3 directory. I'm in general not a fan of deleting fix files, so I'm hesitant to say how many to keep, versus just suggesting to clean out anything but the one in use the next time a new input-data-YYYYMMDD is created.

[gspetro-NOAA]

@gspetro-NOAA the process in the past has always been to just create a new WW3 directory so: input-data-20260617/WW3_input_data_20260811

Depending on how far back you want to maintain backwards compatibility means how many WW3 directories you should keep. I think we kept too many the last time there was a new input-data-YYYYMMDD that was kept. Anytime we create a new input-data-YYYYMMDD we should only keep the last WW3 directory. I'm in general not a fan of deleting fix files, so I'm hesitant to say how many to keep, versus just suggesting to clean out anything but the one in use the next time a new input-data-YYYYMMDD is created.

@BrianCurtis-NOAA @NickSzapiro-NOAA @dpsarmie Any opinion here?

[BrianCurtis-NOAA]

@gspetro-NOAA the process in the past has always been to just create a new WW3 directory so: input-data-20260617/WW3_input_data_20260811
Depending on how far back you want to maintain backwards compatibility means how many WW3 directories you should keep. I think we kept too many the last time there was a new input-data-YYYYMMDD that was kept. Anytime we create a new input-data-YYYYMMDD we should only keep the last WW3 directory. I'm in general not a fan of deleting fix files, so I'm hesitant to say how many to keep, versus just suggesting to clean out anything but the one in use the next time a new input-data-YYYYMMDD is created.

@BrianCurtis-NOAA @NickSzapiro-NOAA @dpsarmie Any opinion here?

I'm not too opinionated here: I agree with Jessica here in keeping one WW3 dir upon a new input-data. If there are space issues, then we can go back and track WW3 dir's and remove any that didn't follow that idea.

[gspetro-NOAA]

Ok, for now, the consensus is that we'll proceed as usual and create a new WW3_input_data_YYYYMMDD directory. WM CMs will discuss a deprecation strategy for input data, both the WW3_input_data_YYYYMMDD directory and the overarching input-data directories.

[gspetro-NOAA]

@mingchen-NOAA Could you sync w/develop so that I can do some pretesting w/the staged data?

[mingchen-NOAA]

@gspetro-NOAA Branch updated.

[gspetro-NOAA]

@mingchen-NOAA I'm seeing an increase of 10 -Wunused-variable warnings in compile_s2sw_32bit_pdlib_debug_gnu coming from:

• WW3/model/src/w3profsmd_pdlib.F90 (5 warnings)
• WW3/model/src/w3profsmd.F90 (3 warnings)
• WW3/model/src/w3updtmd.F90 (2 warnings)

[mingchen-NOAA]

I will take a look at these warnings.

[gspetro-NOAA]

Thanks! The intel test also shows an increase in remark #7712 (unused variables):

• +8 CG
• +1 CLATS
• +1 MAPWN

in the same three files.

[mingchen-NOAA]

WW3 PR has been merged and the hash is 993de9b