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

Allow SHiELD_physics to use the full coupler fluxes. #53

Merged
merged 9 commits into from
Jul 17, 2024

Conversation

JosephMouallem
Copy link
Contributor

Modification needed for the SHiEMOM model where the fluxes from the full coupler are used in the physics.
Developed by @gaokun227

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.

This looks fine to me. I had a couple of questions about the new fields defined in FV3GFS_io.F90 but these are only informational and shouldn't stop this merge. Thank you.

@@ -1451,6 +1484,10 @@ subroutine GFS_physics_driver &
Diag%u1(:) = Statein%ugrs(:,1)
Diag%v1(:) = Statein%vgrs(:,1)
Sfcprop%qsfc(:) = qss(:)

! KGao
Diag%hflx(:) = hflx(:)
Copy link
Contributor

Choose a reason for hiding this comment

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

How do these differ from the existing diagnostics? Is this exposing the behavior of the coupler itself rather than the flux "seen" by the atmosphere?

Copy link

@gaokun227 gaokun227 Jul 18, 2024

Choose a reason for hiding this comment

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

hflx and evap are two new diagnostics, which were to ensure the fields seen by the SHiELD physics are consistent with what in the coupler. They represent the temp and q fluxes (not the sensible and latent heat fluxes).

@@ -6979,6 +7003,30 @@ subroutine gfdl_diag_register(Time, Sfcprop, Gfs_diag, Model, Cldprop, Atm_block
Diag(idx)%data(nb)%var2 => Sfcprop(nb)%uustar(:)
enddo

! KGao
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 so that we can have arrays holding the flux directly from the coupler? If so, why not use the arrays in the Coupling% data structure?

Copy link

@gaokun227 gaokun227 Jul 18, 2024

Choose a reason for hiding this comment

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

Yes, we let the Sfcprop% data structure holds surface layer variables (heat fluxes, ocean temp, z0/zt) passed from the coupler. It is a convenient choice as some fields are already defined. There should be a merge request to the atmos_driver repo to reflect this.

I am not sure of the role of Coupling% in SHiELD physics. I don't think Joseph and I have touched it for the SHiELD-MOM6 coupling.

Copy link
Contributor

Choose a reason for hiding this comment

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

That is fine; I'm not sure whether Coupling% is actually hooked up to anything. Sfcprop is already being used and is convenient, but be aware that it may be altered in subtle ways elsewhere in the physics driver.

Copy link
Contributor

Choose a reason for hiding this comment

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

The coupling arrays may be useful if we need to accumulate something over timesteps instead of passing instantaneous values.

allocate (Coupling%nirbmdi (IM))

@lharris4 lharris4 merged commit c93b388 into NOAA-GFDL:main Jul 17, 2024
2 checks passed
if (Model%sfc_gfdl) then
! kgao - need a logic to ensure sfc_coupled is true when coupled with MOM6
if (Model%sfc_coupled) then
! a version of sfc_diff from coupling with MOM6 by kgao
Copy link
Contributor

Choose a reason for hiding this comment

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

Useful comment much appreciated.

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