update SCM-only time-vary schemes to use timestep_init phase #562
Conversation
grantfirl
commented
Jan 27, 2021
•
grantfirl
commented
- Update SCM-only time-vary schemes to use timestep_init phase
- Move diagnostic clearing back to SCM code since it has been removed in the timestep_init phase of GFS_phys_time_vary
…CMakeLists.txt change in order to compile?)
|
Associated PR: NCAR/ccpp-scm#223 |
|
The change (reversion) in the CMakeLists.txt file is not meant to stay. It was needed in order to compile with the SCM. With the newer version, cmake can't find the ccpp_prebuild-generated cmake files. This is very likely the result of other errors within the SCM build system, but I couldn't figure it out yet. That being said, the timestep_init changes compile/run just fine and are all SCM-only. In fact, it seems like there will no longer be a need to have host-specific versions of GFS_rad_time_vary. |
grantfirl
requested review from
climbfuji,
JulieSchramm and
llpcarson
as code owners
|
The CMakeLists.txt reversion is no longer needed after fixing the SCM build system. |
| use aerinterp, only : read_aerdata, setindxaer, aerinterpol | ||
|
|
||
| use iccn_def, only : ciplin, ccnin, ci_pres | ||
| use iccninterp, only : read_cidata, setindxci, ciinterpol | ||
|
|
||
| #if 0 |
There was a problem hiding this comment.
This has been implemented for FV3 already, will that follow in another PR?
There was a problem hiding this comment.
Yes. This is only to catch up to ccpp-physics as of late January. More PRs will follow to catch up with FV3 develop and ccpp/physics master.
| enddo | ||
| enddo | ||
|
|
||
| #if 0 |
There was a problem hiding this comment.
Yes, I know this has been moved/implemented. Will catch up in followup PR.
|
|
||
| ! Not needed for SCM: | ||
| !> - Call gcycle() to repopulate specific time-varying surface properties for AMIP/forecast runs | ||
| !if (nscyc > 0) then |
There was a problem hiding this comment.
For future "reunification of the .fv3. and .scm. versions, are you planning to harcode nscyc/fhcyc to < 0?
There was a problem hiding this comment.
I hadn't thought about that yet, but that may work (like I had hard-coded radiation timesteps to turn it off when needed). There may be an additional issue with gcycle, IIRC. Right now, it's not even being compiled with SCM. I know that the rad_time_vary is now more-or-less identical between fv3 and scm versions, but I'm not sure about the other time_vary routines. Will need to check on that at some point. That would be a followup PR though (to delete the scm-specific versions when the time comes).
