Skip to content
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

Introduce the legacy CESM WW3 coupling option (VR12-MA) #194

Merged
merged 14 commits into from
Aug 27, 2021

Conversation

alperaltuntas
Copy link
Member

@alperaltuntas alperaltuntas commented Aug 5, 2021

This PR introduces the legacy OCN+WAV coupling approach of CESM to MOM6 (via nuopc cap only). The approach is based on receiving an enhancement factor directly from WW3 and passing it to CVMix (Li et al. 2016). In addition to this new wave coupling method, which is activated by setting WAVE_METHOD = "EFACTOR", the KPP CVMix module has also been refactored such that: (1) When the enhancement factor is not received from WW3, we let CVmix compute the enhancement factor for the existing wave method options as well. (2) Instead of explicitly multiplying diffusivities and viscosities with the enhancement factor, we let CVMix handle enhancement internally.

Tests: aux_mom.cheyenne b4b

@@ -173,12 +174,20 @@ module MOM_wave_interface

! Switches needed in import_stokes_drift
!>@{ Enumeration values for the wave method
integer, parameter :: TESTPROF = 0, SURFBANDS = 1, DHH85 = 2, LF17 = 3, NULL_WaveMethod = -99
integer, parameter :: TESTPROF = 0, SURFBANDS = 1, DHH85 = 2, LF17 = 3, VR12MA = 4, NULL_WaveMethod = -99

Choose a reason for hiding this comment

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

@alperaltuntas, this new wave method option VR12MA here and below is a bit confusing to me. It looks like that all other options are ways to get the Stokes drift. Are we also passing the three Stokes drift components in addition to the Langmuir multiplier from WW3 to MOM6 with this option? If so, maybe we should name it something like WW3? Not sure what's the best way to do this without going into the details of the code... What do you think, @breichl?

Copy link

Choose a reason for hiding this comment

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

I spoke with @alperaltuntas about this as well, so perhaps it is worth considering making it a bit clearer. What if you change the option here to EFACTOR_STRING = "EFACTOR"? This seems self-descriptive enough, and the comment could then be something like "Directly imports Langmuir enhancement factor".

I think it would not make sense to use this naming convention inside KPP though, as it would also make sense to be able to use the efactor with other KPP-LT methods than VR12. In that case, the two options I see (for KPP code) are (1) to create a new LT flag/input parameter just for this KPP-LT method that directly passes the efactor and options to CVMix, essentially as is done within this PR, or (2) to replace the function of the existing VR12 flags (via LT_K_Method and LT_VT2_Method) to pass the "lamult" to CVMix, instead of modifying VT2 and wscales in MOM6 as is currently done. I'll note that I don't think anyone is using the existing KPP-LT codes in any production/testing runs so we don't necessarily have to worry about bitwise reproducing, just maintaining the functionality.

I think the latter option (2) makes the most sense as a long term strategy, though it would require a bit more effort at present. We will also need to introduce a subroutine to compute lamult from Stokes drift so that this would function correctly when Stokes drift is only passed instead of the efactor. That might be done by adding lamult to the waves control structure and then populating it inside of get_Langmuir_number within this module.

I'm open to comments/other suggestions and happy to help with any code changes that this may require.

Copy link
Member Author

Choose a reason for hiding this comment

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

@breichl , I am happy to apply the change you propose for the MOM_wave_interface. As for the KPP module, I am not sure if I understood your proposal fully, but does it make sense to add this new VR12 method as another KPP_LT_VT2_METHOD option? Because I am not sure if we can replace the the function of the existing VR12 flag even if we directly pass the efactor to CVMix, since another key difference between the existing VR12 and the upcoming one is that the former computes the efactor within MOM_CVMix_KPP wheras the latter directly receives it from WW3.

Copy link

Choose a reason for hiding this comment

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

Right, I'm a bit unsure about the best way to do it for that reason. We could start with it as another method for simplicity, but I was also wondering if there is a strategy to make these coupling approaches compatible and avoid some repetitive codes. For example, if we add an optional step that computes the efactor directly from the Stokes drift when not in EFACTOR mode, perhaps embedding it within the code to get the Langmuir number, would that take care of this difference? This could preserve the functionality of the WW3 approach when in EFACTOR mode, but also exercise the same algorithm in "Stokes drift" mode with the difference being where/when the efactor is computed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good, @breichl. I'l try to implement this but may ask for help if I encounter any roadblock.

Copy link
Member Author

Choose a reason for hiding this comment

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

@breichl, the last two commits I just pushed are attempts to address your comments. In short, I've changed the wave_method option to EFACTOR_STRING = "EFACTOR". I've also refactored the KPP CVMix module such that: (1) When available, we pass the enhancement factor received from WW3 to CVMix. Otherwise, we let CVmix compute the enhancement factor. (2) Instead of explicitly multiplying diffusivities and viscosities with the enhancement factor, we now let CVMix handle enhancement internally.

Two issues that remain to be resolved:

  • I am not quite sure how to handle the LT_K_MODE_CONSTANT and LT_VT2_MODE_CONSTANT options with this new way of computing and applying the enhancement factor.
  • Similarly, I am not sure how to distinguish between the two different options of LT_K_SHAPE.

To address the above issues (and the potential issues I am not aware of), feel free to submit any changes to this branch/PR at this point, but I am also happy to chat and come up with a solution together.

…uted and applied: (1) When available, pass the enhancement factor received from WW3. Otherwise, let CVmix compute the enhancement factor. (2) Instead of explicitly multiplying diffusivities and viscosities with the enhancement factor, let CVMix handle enhancement internally.
@breichl
Copy link

breichl commented Aug 25, 2021

This looks great.

To your questions:
(1) I think adding the following LWF16 flags, langmuir_entrainment_opt = 'LWF16' and langmuir_mixing_opt = 'LWF16' in the LT_K_MODE_CONSTANT and LT_VT2_MODE_CONSTANT modes will retain the functionality of those options. We could also just delete these options, they were lightly used for debugging but don't serve much purpose beyond that. If you agree that the LWF16 flags will work that seems an easier solution for now and I can revisit if it is worth keeping them around later.
(2) CVMix looks like it will already deal with this internally based on code I added there a few years ago, so I don't think we need to do anything more. (L1042: https://github.com/CVMix/CVMix-src/blob/master/src/shared/cvmix_kpp.F90)

I think the one thing we need in this code is to restore the Vt2 diagnostic calculation (see L862 of new code). This was commented out when I brought the Vt2 back from CVMix, but now the code is no longer doing that so this should be uncommented:

! compute unresolved squared velocity for diagnostics
if (CS%id_Vt2 > 0) then
!BGR Now computing VT2 above so can modify for LT
! therefore, don't repeat this operation here
! CS%Vt2(i,j,:) = CVmix_kpp_compute_unresolved_shear( &
! cellHeight(1:GV%ke), & ! Depth of cell center [m]
! ws_cntr=Ws_1d, & ! Turbulent velocity scale profile, at centers [m s-1]
! N_iface=CS%N(i,j,:), & ! Buoyancy frequency at interface [s-1]
! CVmix_kpp_params_user=CS%KPP_params ) ! KPP parameters
endif

It will need the additional arguments (the same as is done in the bulk Richardson calculation):
EFactor=LangEnhVT2, & ! Langmuir enhancement factor [nondim]
LaSL = CS%La_SL(i,j), & ! surface layer averaged Langmuir number [nondim]
bfsfc = surfBuoyFlux, & ! surface buoyancy flux [m2 s-3]
uStar = uStar(i,j), & ! surface friction velocity [m s-1]

…tionality of prescribed constant enhancement.
@alperaltuntas
Copy link
Member Author

Thanks, @breichl !

... If you agree that the LWF16 flags will work that seems an easier solution for now and I can revisit if it is worth keeping them around later.

Agreed. Done.

(2) CVMix looks like it will already deal with this internally based on code I added there a few years ago, so I don't think we need to do anything more.

Sounds good.

I think the one thing we need in this code is to restore the Vt2 diagnostic calculation (see L862 of new code). This was commented out when I brought the Vt2 back from CVMix, but now the code is no longer doing that so this should be uncommented

Done. I did move the diagnostic calculation from KPP_calculate to KPP_compute_BLD though since turbulent velocity scale profile (ws_1d) is readily available there.

@gustavo-marques , I believe this is now ready to be merged.

@gustavo-marques gustavo-marques merged commit 380615d into dev/ncar Aug 27, 2021
@alperaltuntas alperaltuntas deleted the merge_ww3_coupling_vr12ma branch December 8, 2021 17:00
alperaltuntas pushed a commit that referenced this pull request Dec 14, 2022
* Fix nudged OBCs for tracers
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.

4 participants