Noah LSM for HAFS #419
Noah LSM for HAFS #419
Conversation
grantfirl
requested review from
climbfuji,
JulieSchramm and
llpcarson
as code owners
…e prep occuring in interstitial schemes
|
So, the question for this and all other PRs is that they are all "made for dtc/develop", whereas it was decided last week that we start the dtc/hwrf-physics branch from the hafs-community forks (which are based on the EMC develop / NCAR master branches). I can of course try to cherry-pick the commits that do not have names like "merge dtc/develop into ...", but just like for the PBL commit something might get lost if it is hidden in one of those commits. |
This work was started before that decision and was based off of dtc/develop to begin with, hence the target. But, I'm also confused as to the desired code management. So, for work that was originally based on dtc/develop that had likely progressed past the hafs-community fork, we need to start a new branch from hafs-community and manually move over our changes to that new branch? Or should we start from the NCAR/master? I guess I'm not understanding why it is beneficial to base the new work off of code that is already "behind" in some sense. I'll do what the group decided; it just must not have sunk in during the meeting what we were supposed to do. |
|
No worries, Grant. Work that has begun off dtc/develop should finish this way; anything new (if there is anything) should be started from the dtc/hwrf-physics branch. This will make it much easier for the hafs people to use and for merging the code to master. Especially my hope is to present all the physics that do not change the results as one package (from dtc/hwrf-physics to master), things like SAS as a separate PR to master and then bring it with the updated baseline to dtc/hwrf-physics.
… On Apr 7, 2020, at 6:17 PM, grantfirl ***@***.***> wrote:
So, the question for this and all other PRs is that they are all "made for dtc/develop", whereas it was decided last week that we start the dtc/hwrf-physics branch from the hafs-community forks (which are based on the EMC develop / NCAR master branches). I can of course try to cherry-pick the commits that do not have names like "merge dtc/develop into ...", but just like for the PBL commit something might get lost if it is hidden in one of those commits.
This work was started before that decision and was based off of dtc/develop to begin with, hence the target. But, I'm also confused as to the desired code management. So, for work that was originally based on dtc/develop that had likely progressed past the hafs-community fork, we need to start a new branch from hafs-community and manually move over our changes to that new branch? Or should we start from the NCAR/master? I guess I'm not understanding why it is beneficial to base the new work off of code that is already "behind" in some sense. I'll do what the group decided; it just must not have sunk in during the meeting what we were supposed to do.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub <#419 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RN3YNTPVZQPM676YM3RLO7AVANCNFSM4LTD5PAQ>.
|
It was straightforward to move this work over to be based off of dtc/hwrf-physics. I'm closing this in favor of #431 . |
Thanks, Grant, you are making my life easier! |
…uplicate symbols error on macOS; ccpp-physics: cleanup CCPP cmake flags part 1; contains "fix the number of 2d fields nsfcprop2d" (NCAR#419) (NCAR#417) - Fixes a bug inGFS_diagnostics.F90 that registered several stochastic variables as diagnostic output even though th arrays are not allocated if the corresponding stochastic option is turned off - Fixes a problem that led to a "duplicate symbols" error on macOS with Intel by removing files from ccpp/CMakeLists.txt that get added automatically by CCPP - Updates the submodule pointer for ccpp-physics for the changes described in Cleanup CCPP cmake flags part 1, remove extra logic that reduces optimization for radiation_aerosols.f, update CODEOWNERS, update README.md NCAR#773 - Contains the changes in fix the number of 2d fields nsfcprop2d NCAR#419 from @HelinWei-NOAA - Updates the submodule pointer for GFDL_atmos_cubed_sphere to include latest JEDI control changes (contributed by @mark-a-potts)
No description provided.