gcycle update#2747
Conversation
|
There are quite a few errors in the test that failed to even run |
@DeniseWorthen Thanks! I just noticed these errors and will update it with the new version. |
|
The hera log file was updated after applying the bug fix. |
|
Note: All tests succeeded except for one timeout. I did not re-run this case, but it was recorded in the previous log as 'FAILED: UNABLE TO COMPLETE COMPARISON'. |
|
@RuiyuSun Just for clarity---almost all cpld tests will have new baselines, correct? And in your latest commit of the logs, the tests which previously failed (the debug tests) are now running, but not B4B. |
@DeniseWorthen Thanks for pointing this out! A correction was made to the dimension of the oceanfrac. @grantfirl Could you confirm that the dimension correction made is correct? The dimension definition was changed from horizontal_loop_extent to horizontal_dimension. Thanks! |
@DeniseWorthen That is right that all cpld tests will have new baseline @XuLi-NOAA. What is B4B? |
|
@DeniseWorthen OK. I know what B4B is now. This PR change the results in the coupled tests. |
|
@RuiyuSun I enjoyed reading your PR description, thank you! Looked up linked figures. As you said there was a connection with radiation, in which case, with these modifications there must be a net change in the net heat flux (downward) - your figures show components (LW, SW, turbulent); I'm trying to get a sense of the change in the total. Do you happen to have that handy? We can connect offline. I don't answer to this question has any bearing whatsoever on this PR (merge). |
|
@sanAkel: Yes, it is interesting and makes sense to see how the net heat fluxe change due to the change described in this PR. The focus of this PR is to see the impact of this gcycle modifcation on the coupled system, and therefore I have tried to see the change at every time step (12 minutes in the regression test), and FHCYC is set to be 1 hour (5 timesteps). Particularly, I intend to see the heat flux responses, since as we understand, in time, the first response/change occurs in radiation, more concretely, the upward longwave radiation, which depends on the surface temperature . I will check the the total heat flux, as you suggested. |
|
Thank you @RuiyuSun, @XuLi-NOAA |
The total heat flux (-shtfl-lhtfl+dlwrf+dswrf-ulwrf-uswrf) has been added to https://docs.google.com/presentation/d/1sDo1rXrq32Fn9g-R2sWYtNx_Qi_0MKDLf0A-PuLaAJs/edit?slide=id.g361819c2807_0_15#slide=id.g361819c2807_0_15 |
Thanks @XuLi-NOAA for adding that. |
|
@FernandoAndrade-NOAA We can start merging process. |
|
Where are the hercules and orion logs? Those RTs were run before the atmos-cubed-sphere PR sync was fixed, right? Hercules/Orion log show 127a341d126a6225a52eed61c4e866e1af82005f FV3/fv3/atmos_cubed_sphere (201912_public_release-414-g127a341 |
|
let me double check |
@jkbk2004 I can start merging when you're ready. Let me know if everything checks out. |
|
Also missing derecho logs BTW |
|
We should be all set now with the new logs, I'll leave a note in sub PRs. |
|
@RuiyuSun @rhaesung new fv3 hash is NOAA-EMC/ufsatm@0eb4102 |
Done! |
jkbk2004
requested review from
FernandoAndrade-NOAA,
NickSzapiro-NOAA and
dpsarmie
13 participants
Commit Queue Requirements:
Description:
This description is written by @XuLi-NOAA
Background
In the uncoupled GFS , a utility, called Gcycle (Global Cycle), is required to apply some constraints or adjustments, such as relaxation to climatology or threshold check, to some surface variables.
Gcycle is still on in GFSv17, even if it has become a coupled system. However, in the transition from the uncoupled to coupled mode, two subtle issues in gcycle application have not been considered carefully enough and are addressed here.
Problem
The lack of two logics, (1) ocean or lake, to distinguish the way to apply the gcycle adjustment to water surface variables, specifically, temperature, sea ice and snow over sea ice and related variables; (2) coupled or uncoupled, to distinguish the way to apply the gcycle adjustment to water surface temperature
Root cause of the problem
The water surface is treated differently (1) over ocean or lake; (2) in coupled or unclouped mode.
Concretely, (1) in a coupled mode, the ocean, and sea ice, is simulated by an oceanic model (MOM6) and an ice model (ICE6) and therefore the sea surface temperature and sea ice adjustment by gcycle is not needed anymore; but the lake still evolves with the NSST model and gcycle, and therefore gcycle is still needed. (2) It is necessary to make it work in uncoupled mode, in which the gcycle is applied to both ocean and lake, therefore, an indicator of the couple mode is needed.
One argument (True or False): Turning off gcycle adjustments over ocean area is unnecessary since the oceanic surface temperature will be over written later on at the NSST run step.
With comprehensive understanding of CCPP sequential execution steps, it has been found out that there are some steps, such as radiation and some interstitial processing, between gcycle and NSST model run, therefore, the turning off of the gcycle adjustments in the coupled mode is absolutely necessary.
It is fair to say this argument is partially true since there is indeed an overwrite of the sea surface temperature. However, the key is that there are steps between gcycle call and the overwrite step.
Solution
To add two logics to determine if the water surface is ocean or lake, and if it is coupled or uncouple, to UFS.
The ocean mask, oceanfrac(1=ocean, 0=non-ocean) is available in ccpp physics can be used to tell if a grid is over ocean or not. Another logical variable, cplflx is available in ccpp code can be used to tell if the system is in coupled or uncoupled mode.
tref(:) = foundation temperature over water surface
tisfc(:) = surface skin temperature over (sea or lake) ice
hice(:) = (sih) sea or lake ice thickness
fice(:) = (sic) sea or lake ice fraction/concentration
weasd(:) = water equiv of acc snow depth over land and (sea or lake) ice
snowd(:) = water equivalent snow depth
snoalb(:) = maximum snow albedo
At present, the code modification is to let the current sfccycle subroutine does what it does (as is), but update the related variables (listed above) at Lake grids only and when the system is in a coupled model. Concretely, this requires to save the listed variables before the call of sfccycle in gcycle.F90, then update them as above after the call of sfccycle.
Only three files need to be modified:
Interstitials/UFS_SCM_NEPTUNE/gcycle.F90
Interstitials/UFS_SCM_NEPTUNE/GFS_phys_time_vary.fv3.F90
Interstitials/UFS_SCM_NEPTUNE/GFS_phys_time_vary.fv3.meta
The code has been done and tested and the impacts are as expeted. See result figures at https://docs.google.com/presentation/d/1sDo1rXrq32Fn9g-R2sWYtNx_Qi_0MKDLf0A-PuLaAJs/edit?slide=id.p1#slide=id.p1
Notes for future:
a. This project focuses on GFSv17, in which NSST is on. The work and test when NSST is off needs to be done for HAFS where NSST is off
b. Stand-alone Gcyele enhancement for sfcanl generation
Commit Message:
Priority:
Git Tracking
UFSWM:
Sub component Pull Requests:
UFSWM Blocking Dependencies:
Documentation:
No documentation update is required for this PR (update a bug)
Changes
Regression Test Changes (Please commit test_changes.list):
PR Updates/Changes Baselines.
Input data Changes:
Library Changes/Upgrades:
Testing Log: