Unnecessary calculations running 1/4 degree MOM6

[pjpegion]

for the 1/4-degree model, the Gent-McWilliams scheme is called, but the results are later ignored, thus wasting CPU time. Setting THICKNESSDIFFUSE = False prevents the call to MOM_thickness_diffuse.F90, shortening the runtime by about 1%.

This will change the MEKE field in the restart file, but doesn't affect the state of the model.

[JessicaMeixner-NOAA]

So one comment from @jiandewang is that the regression tests for ufs-weather-model run with this setting turned on and do compare the restart files. One drawback of having the "production" runs different from what is tested in the regression tests is that we aren't testing it. Seems like that might not be an issue in this case, but something to consider as well.

[jiandewang]

The 1% cpu time saving is based on dat-atm. I launched several parallel jobs last night to see what's the impact on S2S but HERA is off at this moment. My understanding is in S2S fv3 is the bottleneck so this change may not be very necessary. Let's wait when HERA is back.

[JessicaMeixner-NOAA]

@jiandewang I agree -- the atm model is usually the bottleneck so we might not see the benefit right now for prototype 7.

[jiandewang]

add Alistair and Phil's communication here for record:

Phil: Is the bypassing of the Gent-Mcwilliams parameterization intentional, or should KHTH be set to a positive number, and if so, what should that value be?

Alistair's reply:

Yes, it is intentional. The idea behind turning on was that we would be able to more trivially then turn on the scale-aware version of GM that we have but we currently find the latter to degrade the solution. As you have found, turning it off makes no difference. You might want to do this to avoid unnecessary computation. Hopefully we'll find a way to get the scale aware scheme working in OM4.1 but that's for the future

[jiandewang]

HERA is back, I checked the two jobs (cpld_bmark_wave_v16_p7b) I launched last night, one with THICKNESSDIFFUSE=T, one with F, 1st job finished with 11m53s, 2nd one is 1 second less.

[pjpegion]

Guess the coupled model is not load balanced enough to make a difference. Thanks for testing. -Phil

On Tue, Aug 3, 2021 at 4:30 PM jiandewang @.***> wrote:

HERA is back, I checked the two jobs (cpld_bmark_wave_v16_p7b) I launched last night, one with THICKNESSDIFFUSE=T, one with F, 1st job finished with 11m53s, 2nd one is 1 second less.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/global-workflow/issues/392#issuecomment-892208601, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJIRVJEPSLNX4VYBPHVQOBLT3BUYZANCNFSM5BNQTNVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Phil Pegion (he/him/his) Physical Scientist NOAA/Physical Sciences Laboratory (303) 497-7897 @.***

[WalterKolczynski-NOAA]

@JessicaMeixner-NOAA @jiandewang So, this issue from last year is still open. It sounds like the setting should be turned off, even if the practical difference is small. Would this only be for 0p25, or does it extend to other resolutions? Or should we just close this issue?

[JessicaMeixner-NOAA]

This needs to be tested for speed & science impacts before implementing. I'm assuming we just close this for now as MOM6 speed-impacts are not effecting overall model performance at this moment. @jiandewang or @pjpegion might feel otherwise though.

[jiandewang]

Alistair has explained to us that this section is kept in the code intentionally for future enhancement, and our tests indicated the impact is minor. @WalterKolczynski-NOAA this is independent with resolution you can close it now