-
Notifications
You must be signed in to change notification settings - Fork 0
Wave Momentum Coupling #124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Wave Momentum Coupling #124
Conversation
7ccc508 to
8d652e9
Compare
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
1eecde5 to
efde4a8
Compare
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
d8e8c0b to
b1ad138
Compare
|
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 |
|
@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? |
|
@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... |
|
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. |
|
@erinethomas Is the code BFB when waves are switched off? |
The switch file must be parsed in order to conditionally assemble the correct source code.
| description="Charnock coeff accounting for the wave stress (Janssen 1989, 1991)" | ||
| packages="activeWavePKG" | ||
| /> | ||
| <var name="z0wav" type="real" dimensions="nCells Time" units="m" |
There was a problem hiding this comment.
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="" |
There was a problem hiding this comment.
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?
| 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.'); | ||
| } |
There was a problem hiding this comment.
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).
| <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" |
There was a problem hiding this comment.
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.
waveToOceanZonalWindStress = wind stress, waves to ocean (ie.
But then I don't get what the third one is:
waveNetOceanZonalWindStress = ??? Is this
I tried to figure it out from the code, but coupler gooble-d-goop kind of gets in the way.
share/util/shr_flux_mod.F90
Outdated
| ustar = rdn * vmag | ||
| if (wav_atm_coup .eq. 'twoway') then | ||
| if (ustarwav(n) == 0.0_R8 ) then | ||
| ustar = ustarwav(n)+0.1_R8 |
There was a problem hiding this comment.
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?
share/util/shr_flux_mod.F90
Outdated
| implicit none | ||
|
|
||
| ! input variables | ||
| real(R8), intent(in) :: kappa !von Karmen constant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| ! parametrisation for Charney parameter (section 3c of Fairall et al. 2003) | |
| ! parametrization for Charnock parameter (section 3c of Fairall et al. 2003) |

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:
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