update mom6 to its main repo. 20250818 commit

[jiandewang]

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:

MOM6 main repo. is upated on 20250818 which is originally GFDL's change default parameter PR (mom-ocean/MOM6#1670). Need to merge it into dev/emc. See detail description at EMC MOM6 issue NOAA-EMC/MOM6#160

Commit Message:

  * MOM6 - update MOM6 to its main repo. 20250818 (default parameter changes) and cleanup MOM_input. 
  * Add ENABLE_BUGS_BY_DEFAULT = False for all resolution settings and removed all "bug" flags in current MOM_input.
  * DEFAULT_ANSWER_DATA is set to 20250818 but WAVE_INTERFACE_DATA is set to 20230101
  * Equation of state is WRIGHT_FULL now

Priority:

• High: need to use the latest MOM6 code and settings in order to start sensitity test of v17

Git Tracking

UFSWM:

• Closes update MOM6 to its main repo. 20250818 commit #2865
• Closes Compile warnings after #2719 merge #2855

Sub component Pull Requests:

• MOM6: PR161 update MOM6 to its main repo. 20250818 updating (default parameter changes) NOAA-EMC/MOM6#161)

UFSWM Blocking Dependencies:

• None

Documentation:

• No documentation update is required for this PR (please explain).

---

Changes

Regression Test Changes (Please commit test_changes.list):

• PR Updates/Changes Baselines.

Input data Changes:

• None.

Library Changes/Upgrades:

• No Updates

---

Testing Log:

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

[jiandewang]

@DeniseWorthen I don't know that much in detail on this, this is what original PR said:

The default equation of state is now EQN_OF_STATE = "WRIGHT_FULL", in place of the buggy previous default of "WRIGHT"

[DeniseWorthen]

So why would we want to use "buggy" WRIGHT EOS?

[jiandewang]

actually I hesitated a bit last night when I modify that section, let me switch to the new default option

[jiandewang]

@sanAkel FYI

[sanAkel]

@jiandewang It makes no sense to use known buggy options!

Cc: @yangfanglin

[DeniseWorthen]

Looking at the problematic routine, I also see WAVE_INTERFACE_ANSWER_DATE is available. Have you tried modifying that and leaving DEFAULT_ANSWER_DATE at the 2025 value?

[jiandewang]

@DeniseWorthen that is another option in my mind, I am testing
https://github.com/mom-ocean/MOM6/blob/main/src/user/MOM_wave_interface.F90#L334-L338
trying to narrow down the exact date that causing trouble

[jiandewang]

test indicates WAVE_INTERFACE_ANSWER_DATE = 20230101 works but 20230102 and after failed.
I am going to use DEFAULT_ANSWER_DATE = latest but explicit set wave to 20230101

[jiandewang]

the above setting worked for all test cases, will summarize issue and work with GFDL. Hopefully we can remove wave answer date in the next round of PR mom-ocean/MOM6#1676

[jiandewang]

just removed all "BUG" flags in MOM_input (as we set ENABLE_BUGS_BY_DEFAULT=F now)

[jiandewang]

@DeniseWorthen can you help me double check MOM_input ? I added ENABLE_BUGS_BY_DEFAULT = False and removed all other BUG flags (not really too much of that, GRID_ROTATION_ANGLE_BUGS and USE_TRIPOLAR_GEOLONB_BUG were set as F which mean they are using the bug-fix code so they are harmless but no need to be in MOM_input)

[DeniseWorthen]

@jiandewang To be honest, I'm not sure what the setting of USE_LA_LI2016 should be when we are running without waves. I know we are currently using it T in the tests which do not have waves, but I'm not sure that is the right setting.

Can you check w/ someone on the WAV team?

[jiandewang]

@jiandewang To be honest, I'm not sure what the setting of USE_LA_LI2016 should be when we are running without waves. I know we are currently using it T in the tests which do not have waves, but I'm not sure that is the right setting.

Can you check w/ someone on the WAV team?

@JessicaMeixner-NOAA can you tell us who is the right person on wave team for us to ask this question ?

[JessicaMeixner-NOAA]

@jiandewang I'll see if I can look into the USE_LA_LI2016 model setting.

[JessicaMeixner-NOAA]

Okay I just looked back through emails, and USE_LA_LI2016=True when using w/out the wave model and USE_LA_LI2016=False when using the wave model.

The USE_LA_LI2016 is a logical to use the Li et al. 2016 (submitted) formula to determine the Langmuir number. When you are coupling w/a wave component, the wave model is helping calculate that instead.

@jiandewang - is that what you needed or something else?

[jiandewang]

@JessicaMeixner-NOAA this means we are using the correct setting for no wave case. Thanks

[DeniseWorthen]

I just checked a cpld_control_pdlib_p8_intel run directory I have. It does use waves but has USE_LA_LI2016 = True. It seems from what Jessica wrote it should be False (since the WAV model is calculating it instead?).

EDIT: I do see old emails(~2020) w/ a fix of a halo-decomp issue and Alper finding that setting this parameter = F gave restart reproducibility. I think that was a temporary fix, once the halo issue was resolved, we were able to set it T and still get restart-repro w/o waves.

[jiandewang]

I just checked all rt.sh cpld cases, they are all T
URSA: /scratch4/NCEPDEV/stmp/Jiande.Wang/RT_RUNDIRS/Jiande.Wang/FV3_RT/rt_885411
grep 'USE_LA_LI2016' cpld*/INPUT/MOM_input

[JessicaMeixner-NOAA]

I think it's a place where it might be "cleaner" to have it set as false, but it is not expected to change answers when you have a wave component.

[jiandewang]

I carefully read Brandon's original email twice. Set USE_LA_LI2016 to T is correct for both with wave and w/o wave.

[jiandewang]

Out for lunch at this moment, will be in front of computer in 20 minutes

[jiandewang]

MOM6 merged with hash fe9e7bf
UFS submodule reverted

[jiandewang]

sorry I reverted submodule before I saw the approval

[DeniseWorthen]

@jiandewang @JessicaMeixner-NOAA I ran the datm_cdeps_mx025_gefs_intel test for 2 days with this PR and the hash previously. This is the SST difference from ocn_2011_10_02_21.nc. It doesn't look like there is anything dramatic changing---the biggest change seems to be a very small cooling in what I would guess are turbulent regions in the Southern Ocean.

[JessicaMeixner-NOAA]

Thank you @DeniseWorthen !!!

[jiandewang]

@DeniseWorthen Thanks

[jiandewang]

FYI @sanAkel @NeilBarton-NOAA

[sanAkel]

FYI @sanAkel @NeilBarton-NOAA

That is/was the expectation - I.e., these bug fixes do not change the answers in any "systematic way".

[NeilBarton-NOAA]

Thanks @DeniseWorthen !