-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversation
Kun's changes for SHiELD+MOM6 coupling
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.
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(:) |
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.
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?
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.
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 |
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.
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?
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.
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.
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.
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.
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.
The coupling arrays may be useful if we need to accumulate something over timesteps instead of passing instantaneous values.
SHiELD_physics/GFS_layer/GFS_typedefs.F90
Line 1911 in c93b388
allocate (Coupling%nirbmdi (IM)) |
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 |
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.
Useful comment much appreciated.
Modification needed for the SHiEMOM model where the fluxes from the full coupler are used in the physics.
Developed by @gaokun227