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

Include surface ocean current in the computation of air-sea fluxes #311

Merged

Conversation

binli2337
Copy link

@binli2337 binli2337 commented Jan 13, 2024

Description

Update surface layer scheme to include surface ocean current in the computation of air sea fluxes.
Transfer surface ocean current field to nested grids.

Fixes #312

How Has This Been Tested?

The updated code has been tested successfully in the HAFS-MOM6 application.

Checklist:

Please check all whether they apply or not

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules

Co-authored-by @binli2337 ,@BinLiu-NOAA, @WeiguoWang-NOAA, @BijuThomas-NOAA, @hyunsookkim-NOAA, @XuLi-NOAA, @MariaAristizabal-NOAA, @JohnSteffen-NOAA

@lharris4
Copy link
Contributor

Hi, @binli2337 . I take it this is to be able to transmit the surface currents between the parent and nested grids, something that the physics itself does not support? Is this capability needed for other variables as well?

Thanks,
Lucas

@binli2337
Copy link
Author

@lharris4 Sea surface temperature (tsfco) also needs to be transferred from parent grid to nested grid. SST was already been transferred from parent to nested gird before this PR.

@BinLiu-NOAA
Copy link

Hi, @binli2337 . I take it this is to be able to transmit the surface currents between the parent and nested grids, something that the physics itself does not support? Is this capability needed for other variables as well?

Thanks, Lucas

@lharris4, you are right. The transit of coupling variables (SST, Sea Surface Current) between the parent and nested grids currently relies on the FV3dycore and FMS capabilities. It cannot be done in the physics side currently. As @binli2337 mentioned, this has been previously implemented for SST and sea surface roughness variables. And in this PR, we are trying to add the SSC u/v components.

Meanwhile, you might recall the ongoing PR #272 from @dkokron, which should help to speed up the parent to nest transition process.

Thanks!

Copy link
Contributor

@lharris4 lharris4 left a comment

Choose a reason for hiding this comment

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

I think this is OK given that it extends a previously defined capability used for operations. However I really think this is something the flux coupler needs to handle, by transmitting surface ocean conditions (SST, SSH, Us, Vs, roughness length, etc.) to the appropriate domain, nested or not.

I would appreciate if you would open an issue within the coupling library.

Thanks,
Lucas

Comment on lines 1272 to 1273
real, _ALLOCATABLE :: usfco(:,:) _NULL !< sea surface current (zonal) from NCEP/GFS (m s-1) -- tile
real, _ALLOCATABLE :: vsfco(:,:) _NULL !< sea surface current (meridional) from NCEP/GFS (m s-1) -- tile
Copy link
Contributor

Choose a reason for hiding this comment

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

Are these necessary? I don't see them being used in your feature branch.

Copy link
Author

Choose a reason for hiding this comment

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

@bensonr The variables usfco and vsfco are used in the updated surface layer scheme in ccpp-physics. The updated surface layer scheme is used in both parent and nested grids,

Choose a reason for hiding this comment

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

@bensonr I think this is a good catch. The two lines of defining usfco/vsfco are not needed here inside the FV3dycore. The two variables are needed in the FV3ATM level though (including inside the moving_nest dir). @binli2337 is currently double checking and testing, will reply to this thread once he confirms. Thanks!

@BinLiu-NOAA
Copy link

I think this is OK given that it extends a previously defined capability used for operations. However I really think this is something the flux coupler needs to handle, by transmitting surface ocean conditions (SST, SSH, Us, Vs, roughness length, etc.) to the appropriate domain, nested or not.

I would appreciate if you would open an issue within the coupling library.

Thanks, Lucas

Thanks, @lharris4! And agreed. We already have an issue created under ufs-weather-model (ufs-community/ufs-weather-model/issues/1884) regarding establish/optimize the capability of coupling both FV3ATM parent domain and static/moving nest domain with other earth modeling components. Thanks!

Copy link

@BinLiu-NOAA BinLiu-NOAA left a comment

Choose a reason for hiding this comment

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

Changes look good to me.

@lharris4
Copy link
Contributor

lharris4 commented Jan 23, 2024 via email

@zach1221
Copy link

zach1221 commented Feb 1, 2024

Testing is complete on ufs-wm 2104. @bensonr would you be able to merge this PR for us please?

@bensonr bensonr merged commit 6663459 into NOAA-GFDL:dev/emc Feb 1, 2024
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.

5 participants