Missing diurnal cycle in surface LWup when ocean coupling is present

[benwgreen]

Description

The current suite definition file for coupled global UFS, suite_FV3_GFS_v17_coupled_p8_ugwpv1.xml has the following sequence (non-relevant parts omitted):

<subcycle loop="1">
  ...
  <scheme>GFS_surface_composites_pre</scheme>
  <scheme>dcyc2t3</scheme>
  <scheme>GFS_surface_composites_inter</scheme>
  <scheme>GFS_suite_interstitial_2</scheme>
</subcycle>
<!-- Surface iteration loop -->
<subcycle loop="2">
  <scheme>sfc_diff</scheme>
  <scheme>GFS_surface_loop_control_part1</scheme>
  <scheme>sfc_nst_pre</scheme>
  <scheme>sfc_nst</scheme>
  <scheme>sfc_nst_post</scheme>
  ...
</subcycle>

In this ordering, Line 263 of GFS_surface_composites_pre sets "tsfc_wat" ("surface_skin_temperature_over_water" in GFS_surface_composites_pre.meta) to "tsfco" ("sea_surface_temperature"). But, "sea_surface_temperature" when ocean coupling is on is set to the layer 1 temperature from the ocean model, which is NOT the true skin temperature.

The dcyc2t3 routine (see if block on Line 367 of dcyc2t3.f) uses "tsfc_wat" ("surface_skin_temperature_over_water"), which in the ocean coupled case is still ocean layer 1 temperature, to compute adjsfculw_wat ("surface_upwelling_longwave_flux_over_water"), which is a pure diagnostic.

The ocean skin temperature (using, e.g., sfc_nst*) is only computed after dcyc2t3 computes the surface upwelling longwave flux over water.

Because there is an extremely weak diurnal cycle in the ocean model's layer 1 temperature, there is a very weak, unrealistic, diurnal cycle in the diagnostic "surface_upwelling_longwave_flux_over_water" when ocean coupling is turned on.

One final note: I see a suite definition file for coupled HAFS, suite_FV3_HAFS_v2_coupled.xml, but an important difference is that sfc_ocean (which does NOT update ocean skin temperature, and only uses the ocean's layer 1 temperature) is used instead of the three sfc_nst* files. We should have discussions with HAFS developers, but that can wait.

Solution

There is more than one possible solution, and I believe each of the ones that I will list have strengths and weaknesses. There may be another possible solution that I have not considered.

The most straightforward solution would be to re-compute "surface_upwelling_longwave_flux_over_water" by pasting the code from the if block on Line 367 of dcyc2t3.f into sfc_nst.f90 or sfc_nst_post.f90. We would also need to update the .meta file accordingly.

This is not really an elegant solution, but it would not require changes to ufsatm.
Another downside is that sfc_diff (in its first iteration) will still use the temperature of the top ocean layer as a bottom boundary condition, rather than using a true skin temperature.

We would need @XuLi-NOAA to help if we choose this path.

Alternatives (optional)

Another solution would be to create yet another variable that saves the ocean skin temperature (computed by sfc_nst*) between physics time steps, and uses this saved value from the previous time step to compute adjsfculw_wat in the next time step. The downsides are (1) creation of yet another variable, requiring also modifications to ufsatm; and (2) a slight temporal mismatch between the diagnosed upward longwave, and the associated skin temperature.

A third solution would be to have a more thorough reorganization/refactoring of dcyc2t3, but that could get unwieldy quickly.

Attention to

@XuLi-NOAA @yangfanglin @XiaqiongZhou-NOAA @ShanSunNOAA

Related to (optional)

We may eventually need to open an issue in ufsatm, but I want to hold off until we decide how to proceed.