Update MOM6 cap for 2-way ocean-wave coupling for HAFS #143
Conversation
|
I think doing this via a hard-coded FillValue is problematic. It may work in UFS, but what about other users of the cap? Have you tried implementing this via a logical control flag (eg You're also only checking one component of the stokes drift. |
|
agree with @DeniseWorthen , NCAR is also using nuopc driver for their system |
|
@DeniseWorthen ,@jiandewang Thank you for the suggestions. I will try to use the case_name option. |
|
@binli2337 I am trying to understand your logic here. |
|
@jiandewang For non-hafs cases, the case_name might be ufs.cpld, ufs.atmw, DATM_CFSR, DATM_GEFS_NEW, etc. You can find the setting for case_name in the parm/ufs.configure*IN files. |
| @@ -89,6 +90,7 @@ subroutine mom_import(ocean_public, ocean_grid, importState, ice_ocean_boundary, | |||
| real(ESMF_KIND_R8), allocatable :: stkx(:,:,:) | |||
| real(ESMF_KIND_R8), allocatable :: stky(:,:,:) | |||
| character(len=*) , parameter :: subname = '(mom_import)' | |||
| real(ESMF_KIND_R8), parameter :: fillValue = 9.99e20_ESMF_KIND_R8 | |||
There was a problem hiding this comment.
@sanAkel The missing value (or fillvalue) is set in CMEPS and imported to MOM6 cap and WW3 cap. Updates in this PR are to provide a temporary fix by converting the missing value to 0 so that the coupled HAFS application can run for the moment. Once WW3 output from a global model is available, the global WW3 output can provide valid values in the non-overlapped regions and this fix can be removed. The updates in this PR are made in the cap so that these updates do not affect other applications using the MOM6 model. A namelist option (for the zero number) is not used because we plan to convert the missing value to 0 (the only option). Thanks for reviewing the updates.
There was a problem hiding this comment.
@binli2337 Sorry---we're committing this to our repos, only to then turn around and remove it? Why does it need to be committed outside of your own forks in hafs-community?
There was a problem hiding this comment.
@DeniseWorthen Before a global coupled forecast system is in operation, we need these updates for a possible operational HAFS system that includes two-way ocean-wave coupling. It is better to use the updated model code from the develop branch of ufs-weather-model. Thanks!
There was a problem hiding this comment.
@binli2337 Regardless of the order/sequence of merge,
my suggestion is to remove parameter in:
real(ESMF_KIND_R8), parameter :: fillValue = 9.99e20_ESMF_KIND_R8
There was a problem hiding this comment.
You can always update your HAFS community from UWM-develop and have 'updated model code'. What goes operational---the code from HAFS community or the code from UWM-develop?
There was a problem hiding this comment.
@DeniseWorthen The ocean domain and wave domain in the hafs tests are basically overlapped. (98W-8W,1.5N-45.5N) for WW3 and (-98-8W, 1.76N-45.8N) for MOM6. I will add a new parameter in the ufs.configure to indicate that the missing stokes drift is set to zero or not. The default setting is false. For the HAFS with MOM6 applications, the parameter will be set to true if the ocean and wave domain are nearly overlapped. Thanks for reviewing the code.
There was a problem hiding this comment.
@sanAkel The missing value (or fillvalue) is set in CMEPS and imported to MOM6 cap and WW3 cap. Updates in this PR are to provide a temporary fix by converting the missing value to 0 so that the coupled HAFS application can run for the moment. Once WW3 output from a global model is available, the global WW3 output can provide valid values in the non-overlapped regions and this fix can be removed. The updates in this PR are made in the cap so that these updates do not affect other applications using the MOM6 model. A namelist option (for the zero number) is not used because we plan to convert the missing value to 0 (the only option). Thanks for reviewing the updates.
@binli2337 this will put dev/emc MOM6 repo. in a very bad status as I won't be able to ask MOM6 community to review and push it to its main repository. In the meantime if EMC has another internal PR, then it has to be build upon this PR which will again prevent me from asking external to review and push back to main (before you revert your PR).
|
@jiandewang We can coordinate on when to send PRs to be merged with mom-ocean. But meanwhile, I think we should let the HAFS group's work proceed and progress ... when they have resolved ⬆️. |
| type(ocean_public_type) , intent(in) :: ocean_public !< Ocean surface state | ||
| type(ocean_grid_type) , intent(in) :: ocean_grid !< Ocean model grid | ||
| character(ESMF_MAXSTR) , intent(in) :: casename !< Case name for the experiment | ||
| logical, optional , intent(in) :: set_missing_stks_to_zero !< If true, set missing stokes drift to zero |
There was a problem hiding this comment.
use continuous line otherwise it will fail to meet doxgen requirement
The mom_cap_methods.F90 file located in the MOM6/config_src/drivers/nuopc_cap directory is revised to convert imported Stokes drift components from a missing value (9.99e20) to zero. This update doesn't have any impacts on global applications.