Modifications for ufs-coastal app

[DeniseWorthen]

Commit Queue Requirements:

• Fill out all sections of this template.
• All sub component pull requests have been reviewed by their code managers.
• Run the full Intel+GNU RT suite (compared to current baselines) on either Hera/Derecho/Hercules
• Commit 'test_changes.list' from previous step

---

Description:

Updates WW3 for modifications and fixes required by UFS-Coastal App

Commit Message:

* UFSWM - adds additional compile switch and namelist changes required for WW3 in Coastal App
  * WW3 - add export fields required for coupling with SCHISM

Priority:

• Normal (but PR has been held since late summer due to PR pause in WW3 repo)

Git Tracking

UFSWM:

• required by Improve WW3 mesh cap to allow using vortex formulation in ocean side oceanmodeling/WW3#11

Sub component Pull Requests:

• WW3: Add fields and fixes to dev/ufs-weather-model branch, as required by Coastal App NOAA-EMC/WW3#1291

UFSWM Blocking Dependencies:

• None

---

Changes

Regression Test Changes (Please commit test_changes.list):

• PR Updates/Changes Baselines.

None

Input data Changes:

• None.

Library Changes/Upgrades:

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

---

Testing Log:

• RDHPCS
  • Hera
  • Orion
  • Hercules
  • Jet
  • Gaea
  • Derecho
• WCOSS2
  • Dogwood/Cactus
  • Acorn
• CI
• opnReqTest (complete task if unnecessary)

[uturuncoglu]

@DeniseWorthen Do you think that we need to find more meaningful aliases for the new fields defined in the dictionary. We could try to come up a set of standard names for them but not sure. Let me know what you think?

[DeniseWorthen]

@uturuncoglu I'm not sure how useful the aliases are if we have the description. So, for example we could make an alias for Sw_ubry but it would basically be the description, something like alias: near_bottom_rms_wave_velocities_y? Do you know if SCHISM for example would prefer to import a field using a descriptive alias?

I do see now I should have probably named some of the new fields with "Fw" (as fluxes) and not "Sw" as states.

[uturuncoglu]

@DeniseWorthen Yes, SCHSIM follows convention like that. See following part, https://github.com/oceanmodeling/schism-esmf/blob/12e2ce43475fe85212c60de7894524d22a1bab96/src/schism/schism_nuopc_cap.F90#L414. It is not big deal and I am using short names at this point for the implementation but we might consider to add aliases and use them in the SCHSIM side. anyway, I'll let you know when PR is ready in ufs coastal side. So, you could check it.

[DeniseWorthen]

I see, thanks. We definitely might need aliases then.

[uturuncoglu]

@DeniseWorthen @JessicaMeixner-NOAA @janahaddad We had a meeting with costal team today. Here is our proposal,

• Let's keep this PR and also WW3 one active for now. So, it might be merged with the UFS WM around November time frame (waiting in freeze mode 2-3 months) once WW3 team have more resource. We have no rush at this point and we could still test the implementation in our end without any issue.

• In the mean time, I'll create a new branch in our UFS WM fork to bring all these changes. This will allow us to have further test in vortex coupling with a new configuration (we are working on it in Coastal side) and also create new RT to test it regularly. It will also help us to find issues in the coupling if we have and then we could fine tune the PR in here if it is required.

• Then, once top level UFS WM PR is merged, we could sync UFS Costal fork to get all the changes.

Anyway, let me know what do you think about this plan. We are open any other suggestion at this point.

[DeniseWorthen]

@uturuncoglu I do think it is a good idea for Coastal to test the changes in the WW3 cap as much as possible while we wait for the stoppage of PRs in WW3 to lift. Also keep in mind that once the stoppage lifts, PRs to dev/ufs-weather-model will most likely be further delayed as community development (going to the develop branch) will also need to proceed.

Also, I wanted to make Coastal aware of Issue NOAA-EMC/WW3#1298 in case you haven't seen it.

[uturuncoglu]

@DeniseWorthen That is great. BTW, Thanks for pointing the PIO PR.

[DeniseWorthen]

This PR is ready and now contains no baseline change since binary restart are no longer used for any UWM test. It has been held since late summer due to PR pause in WW3.

[jkbk2004]

@DeniseWorthen Go ahead to sync up. We can start working on this pr. @FernandoAndrade-NOAA @BrianCurtis-NOAA FYI

[DeniseWorthen]

Thanks. It should be ready to combine @uturuncoglu

[uturuncoglu]

@JessicaMeixner-NOAA @DeniseWorthen @jkbk2004 I am not sure about the latest decision but it is good to me to combine with the land PR. Let me know if you need anything from my end.

[jkbk2004]

@uturuncoglu I think it depends on the scope of baseline changes expected from this pr. @DeniseWorthen This PR only to support coastal app, right? No impact to existing baseline tests, right?

[uturuncoglu]

@jkbk2004 Sure. No worries. Just decide what you think best. Both works for me. Thanks again for your help.

[DeniseWorthen]

I tested this PR last week on Hercules (disk quota issues on Hera) and there were no baseline changes. This PR merges into the mesh cap fields which the CoastalApp depends on, but are unused currently in UFS.

[jkbk2004]

I tested this PR last week on Hercules (disk quota issues on Hera) and there were no baseline changes. This PR merges into the mesh cap fields which the CoastalApp depends on, but are unused currently in UFS.

@DeniseWorthen Thanks for confirming! It's better to combine with #2556 since both PRs are no baseline change.

[jiandewang]

That will be great. I can push dev/EMC restart feature back to MOM main repo. once this is merged to dev/emc. NCAR is waiting for me to issue their PR.

[jkbk2004]

@DeniseWorthen Can you merge in https://github.com/jiandewang/ufs-weather-model/tree/feature/update-MOM6-20241127 to combine the PRs?

[DeniseWorthen]

Hold on, I need to add the changes in the mom6_files.cmake

[DeniseWorthen]

@jiandewang Please check.

[jiandewang]

@DeniseWorthen Just checked, MOM6 is pointing to the right branch and mom cmake list is using the updated one. Thanks.