Feature/rad fix djs #7
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix to canopy arrays definitions: add intent
… into feature/gfdlmpv3
… into feature/gfdlmpv3
… into feature/gfdlmpv3
This reverts commit 3115d2c.
… into feature/gfdlmpv3
…ers.F90; update CODEOWNERS physics/docs/ccpp_doxyfile
… into feature/gfdlmpv3
…ochemistry-diagnostics
… into feature/rad-fix_djs
Combo PR (merge from NCAR/main, ECMWF GWD, maxmf bugfix, NEPTUNE reproducibility, mersenne bugfix)
GFDLMP-v3 and TEMPO MP microphysics
Adding Integrated Canopy Effects to CCPP/PBL Scheme
… into feature/rad-fix_djs
Combination of 264,265,291 (MERRA2 3-hr, photochem diag, prog closure SFS)
… into feature/rad-fix_djs
Author
Owner
|
@dustinswales I pulled the two new commits from this PR into ufs-community#262. I then tested with the SCM (it successfully ran and smoothed out the offending radiation diagnostics) and just finished UFS RTs. I need to double-check the results of the UFS RTs, but this has effectively been merged. I don't know why this PR has like 250 commits when the one into ufs/dev has much fewer? |
Author
|
@grantfirl Not sure what's going on with the commit history in here? But you grabbed the needed pieces for the PR, and I'm not curious enough to chase it down :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@grantfirl This PR unwinds some of Larissa's changes, putting the radiation diagnostics back into the Radiation Group, from dcyc2t3.F90 -> GFS_radiation_post.F90. I was able to reproduce results for the control_c384 test (one the failing tests).
Also, this bring this branch up-to-date with ufs-community:develop
Deatils:
Common radiation diagnostics are isolated to a subroutine, which is called for both G/GP. The wrinkle is that G and GP interface at different levels, by this I mean G provides HRs whereas in GP you need to compute HRs from the fluxes. So there's more work to get the GP outputs to where they need to be before calling the (common) diagnostic routine. I tried to explain this in the module description.
For GP, we could move the computation of HRs into rrtmg_lw(sw)_main.F90. This would put GP on equal footing with G in the sense that it makes GP consistent with the tendency approach you've been spearheading.
(Sidenote: I would still prefer to keep the mapping from the flat 2D flux fields to the UFS native DDTs outside of rrtmgp_lw(sw)_main.F90, with the hope that someday we could replace this DDT with flat fields in RRTMG. Then GFS_radiation_post would really be GFS_radiation_diagnostics and rrtmg_lw and rrtmg_sw wouldn't rely on a host-specific DDT)