Skip to content

Conversation

@erinethomas
Copy link
Collaborator

@erinethomas erinethomas commented Mar 12, 2025

This is a major PR and requires review before being opened in E3SM master.
NOTE: the code modification includes wave impacts to the default surface flux scheme located here: share/util/shr_flux_mod.F90

NEW WAVE MOMENTUM COUPLING FEATURE
The new coupling included two primary code features related to wave coupling:

  1. Full momentum coupling between WW3, MPAS-Ocean is being implemented.
  2. Additionally, wave impacts are being included in the surface flux calculations through the default surface flux scheme (default flux scheme is based on Large and Yeager 09)

This discussion is for the purpose of getting a preliminary code review and feedback before an official PR is opened into E3SM.

The use of WW3 is 'stealth' in that WW3 is NOT a standard component of E3SM for production runs. However, the implementation of wave-ocean-atm coupling in this PR defines the default coupling based upon the COMPSET used.
For example, a fully coupled base with active waves (B compset + WW3) will assume full, two-way coupling between WW3-EAM-MPASO and MPAS-SI. (note: limited wave-ice coupling for now, full wave-ice coupling coming in near future). On the other hand, if a data atmosphere used, like in a G Case+WW3, EAM-WW3 coupling will default to "one-way" (data winds passed to WW3) while full two way coupling is used between the active components of WW3 and MPAS-O/MPAS-SI.

A draft of the new Feature overview document can be found here:
https://www.overleaf.com/7869147119cznjzdtnjwxb#784344

@erinethomas erinethomas force-pushed the ww3/wave-momentum-coupling branch from 7ccc508 to 8d652e9 Compare March 12, 2025 21:54
xylar added 3 commits March 28, 2025 17:41
In the MPAS Framework, we were previously trying to use unknown
field types in I/O but we instead want to raise a critical error
anytime unknown types occur
@erinethomas erinethomas force-pushed the ww3/wave-momentum-coupling branch from 1eecde5 to efde4a8 Compare April 3, 2025 21:41
whannah1 and others added 13 commits April 14, 2025 08:42
SCORPIO's WITH_HDF5 CMake option was previously disabled by default
for versions earlier than 1.5.0. Now that the submodule has been
updated to version 1.7.0, it is safe to enable this option when
HDF5_ROOT is set in the environment.
CMake's built-in FindHDF5 fails on Frontier with compilers like
craycray-mphipcc due to reliance on unavailable compiler wrapper
tools. It also fails to propagate expected include paths, leading
to hdf5.h not found errors.

This commit adds a simple, custom FindHDF5.cmake to replace CMake's
built-in module:
* Avoids compiler wrapper logic
* Uses HDF5_ROOT to locate headers and libraries
* Defines a proper hdf5 target with include paths

FindPIO.cmake is also slightly updated to:
* Remove unnecessary COMPONENTS in find_package(HDF5)
* Append the hdf5 target to PIOLIBS for proper include
  path propagation
On Frontier, HDF5_ROOT was previously unset due to known CMake
issues. Since those issues are now resolved, this commit restores
HDF5_ROOT support to enable proper SCORPIO configuration.

On Chrysalis, loading the HDF5 module does not automatically define
HDF5_ROOT. This commit sets it explicitly using the path to h5dump.
EAMxx: Remove unused var in MAM4xx microphysics init_temp

Remove unused var in MAM4xx microphysics init_temp

[BFB]

* mahf708/eamxx/mamxx-small-warning:
  EAMxx: remove unused mam mp init_temp
ZM cleanup - consolidate microphysics

This phase of the ZM clean is focused on further modularization and
consolidation of microphysics routines. Including new modules for
ZM micro history methods (zm_microphysics_history.F90) and aerosol
specific information for ZM micro (zm_aero.F90).

[non-BFB] only for pm-cpu_intel tests

* whannah/eam/zm-cleanup-06:
  minor cosmetic fix
  bug fix - mixed up values
  add line return at EOF
  misc cleanup and fixes
  implement zm_microphysics_register
  update zm_microphysics_history methods
  misc bug fixes
  create zm_aero module
  add zm_microp_st_alloc call to zm_conv_tend
  consolidate ZM micro outfld calls into new zm_microphysics_history module
  add zm_microp_st_dealloc to cleanup zm_conv_tend
  update permissions for zm_microphysics.F90
@erinethomas erinethomas force-pushed the ww3/wave-momentum-coupling branch from d8e8c0b to b1ad138 Compare May 6, 2025 00:09
@erinethomas
Copy link
Collaborator Author

This code has been rebased (as of May 6), and recent tests are passing. The multi-decadal long simulation is now underway on Perlmutter (MPAS-Analysis results will be posted once they are complete). This code is now ready for preliminary review. @sbrus89 @OlawaleClimate @proteanplanet @vanroekel

@vanroekel
Copy link
Collaborator

@erinethomas did something happen with the commits here? There are a lot of files in your change list that I'm assuming aren't touched by you. Can you give a list of what files to review?

@erinethomas
Copy link
Collaborator Author

@vanroekel there appears to be some differences between the master on Ocean discussion (slightly out of date) and the E3SM master I recently rebased my code on...
I have actively changed the following 26 files:
Screenshot 2025-05-08 at 2 28 36 PM

@erinethomas
Copy link
Collaborator Author

the most critical file needed for review is "share/util/shr_flux_mod.F90" - this is where all modifications to the default surface flux scheme are performed to incorporate the impact of wave coupling.

@proteanplanet
Copy link
Collaborator

@erinethomas Is the code BFB when waves are switched off?

description="Charnock coeff accounting for the wave stress (Janssen 1989, 1991)"
packages="activeWavePKG"
/>
<var name="z0wav" type="real" dimensions="nCells Time" units="m"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a bit more descriptive variable name? Maybe waveSurfaceRoughnessLength? Or something a little shorter.

description="surface Roughness length accounting for the wave state"
packages="activeWavePKG"
/>
<var name="ustarwav" type="real" dimensions="nCells Time" units=""

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, maybe waveFrictionVelocity to match surfaceFrictionVelocity?

Comment on lines +683 to 689
if ($COMP_WAV eq 'ww3' and $COMP_OCN eq 'mpaso' ) {
add_default($nl, 'config_use_active_wave', 'val'=>'.true.');
add_default($nl, 'config_momentum_use_active_wave', 'val'=>'.true.');
} else {
add_default($nl, 'config_use_active_wave', 'val'=>'.false.');
add_default($nl, 'config_momentum_use_active_wave', 'val'=>'.false.');
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an instance where config_use_active_wave = .true. but config_momentum_use_active_wave = .false.?

If not, is there a reason for having a second config parameter just for the momentum? Seems like if you have active waves on, you'll probably want momentum coupling of the waves to the ocean too, no? Or is there an instance where you would want momentum coupling to the ocean off even if the waves are active? Otherwise I would say we can consolidate to just using the first config option (config_use_active_wave).

Comment on lines +3954 to +3976
<var name="waveSupportedZonalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Zonal Wave supported stress (Stress from atmosphere to waves)"
packages="activeWavePKG"
/>
<var name="waveSupportedMeridionalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Meridional Wave supported stress (Stress from atmosphere to waves)"
packages="activeWavePKG"
/>
<var name="waveToOceanZonalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Zonal Wave to ocean stress"
packages="activeWavePKG"
/>
<var name="waveToOceanMeridionalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Meridional Wave to ocean stress"
packages="activeWavePKG"
/>
<var name="waveNetOceanZonalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Zonal Net ocean wind stress by wave model"
packages="activeWavePKG"
/>
<var name="waveNetOceanMeridionalWindStress" type="real" dimensions="nCells Time" units="N m^{-2}"
description="Meridional Net ocean wind stress by wave model"
packages="activeWavePKG"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on these descriptions alone, its really hard to differentiate all of these. I think the first two are:
waveSupportedZonalWindStress = wind stress, atmosphere to waves (ie. $\tau_{a:w}$ in your Overleaf doc)
waveToOceanZonalWindStress = wind stress, waves to ocean (ie. $\tau_{w:o}$ in your Overleaf doc)
But then I don't get what the third one is:
waveNetOceanZonalWindStress = ??? Is this $\tau_{ocn}$ in your Overleaf doc?

I tried to figure it out from the code, but coupler gooble-d-goop kind of gets in the way.

ustar = rdn * vmag
if (wav_atm_coup .eq. 'twoway') then
if (ustarwav(n) == 0.0_R8 ) then
ustar = ustarwav(n)+0.1_R8
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what this is doing. if ustarwav(n) == 0 why add it again? Why add a hard coded 0.1?

implicit none

! input variables
real(R8), intent(in) :: kappa !von Karmen constant
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
real(R8), intent(in) :: kappa !von Karmen constant
real(R8), intent(in) :: kappa !von Karman constant

if (wav_atm_coup .eq. 'twoway') then
charn = charnsea !use Charnock coefficient from active wave model (Janssen 1989, 1991)
else
! parametrisation for Charney parameter (section 3c of Fairall et al. 2003)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
! parametrisation for Charney parameter (section 3c of Fairall et al. 2003)
! parametrization for Charnock parameter (section 3c of Fairall et al. 2003)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.