corresponding changes to making diag_soil_resp LOGICAL#680
corresponding changes to making diag_soil_resp LOGICAL#680JhanSrbinovsky wants to merge 3 commits intomainfrom
Conversation
|
Note: "icycle" declared in casadimension and distributed through much of science code via inheritance in casa_variable. Online (in AM3) "icycle" as declared in casadimension is populated by the "icycle" read through namelist. We will likely use this method as a stop gap mechanism for the the rest of the namelist, where appropriate. |
There was a problem hiding this comment.
Thanks Jhan, this looks like a nice quality of life change.
I'm just thinking it might be nice to address the wider namelist problems in #660 somewhat together in a big batch to avoid having to update our namelist inputs (which live outside this repo) too often?
|
whatever suits mate :). I have got use to small steps per PRthat's all. I was hoping that this would be the only change I was going to make on the CABLE:main side anyway (for now). But now that I think of it, I probably don't even need to. How about for now, I'll organize what we need on the AM3 side and then we'll return to it. At present in AM3 all these "namelist" configurations (except icycle) are hard-wired in the code. After 12 months of juggling configurations in ESM1.6 I can see that this isn't going to work very well, so I need to pull it all out. The "diag_resp_soil" just happened to be the first one and there is a comment with it inline that has been there for years to make this a LOGICAL switch. |
CABLE
Thank you for submitting a pull request to the CABLE Project.
Description
Please include a brief summary of the change and list the issues that are fixed.
Please also include relevant motivation and context.
You can link issues by using a supported keyword in the pull request's description or in a commit message:
Fixes #(issue)
Type of change
Please delete options that are not relevant.
Checklist
Testing
Are the changes bitwise-compatible with the main branch? If working on an optional feature, are the results bitwise-compatible when this feature is off? If yes, copy benchcab output showing successful completion of the bitwise compatibility tests or equivalent results below this line.
Are the changes non bitwise-compatible with the main branch because of a bug fix or a feature being newly implemented or improved? If yes, add the link to the modelevaluation.org analysis versus the main branch or equivalent results below this line.
Please add a reviewer when ready for review.
📚 Documentation preview 📚: https://cable--680.org.readthedocs.build/en/680/