-
Notifications
You must be signed in to change notification settings - Fork 20
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
Conversation
The export of ice fraction was previously added for the newly added CFC module.
…solving conflicts
src/user/MOM_wave_interface.F90
Outdated
@@ -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 |
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.
@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?
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 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.
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.
@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.
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.
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.
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.
Sounds good, @breichl. I'l try to implement this but may ask for help if I encounter any roadblock.
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.
@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.
This looks great. To your questions: 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 It will need the additional arguments (the same as is done in the bulk Richardson calculation): |
…tionality of prescribed constant enhancement.
Thanks, @breichl !
Agreed. Done.
Sounds good.
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. |
* Fix nudged OBCs for tracers
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