Dynamics Refactor #176
Dynamics Refactor #176
Conversation
…s the calculation of model-day for phenology.
…placing it with bc_in. Temperature_inst for all calls but fire are also purged. Compiles and runs, not regression tested.
…. ldomain%area(g) is still called in fire model, as well as masterproc and use_spitfire.
…arameters passed during initialization. Tracked down other instances of use, and also fixed calls to clm version of r8 or iulog when found.
…he globals at the top of FatesInterfaceMod. master had a slightly different variable name, while the head had added cp_masterproc.
…on of boundary conditions was using numPatchesPerCohort while master changed that to maxPatchesPerCohort.
…wrapper. Essentially it was just a wrapper that appeared only once within another wrapper.
|
@rosiealice, can you review my changes to the fire model, specifically the removal of the grid area? |
…oc variable, while master had the use_fates_plant_hydro variable, both added to same section. Both are valid in the merge.
|
Resolved conflicts from merging master. All tests PASS. |
|
From email discussion with @rosiealice: This is OK if the ignition rate that we use is per unit area. In that case, the number of fires is proportional to the size of the grid cell, and so everything drops out. If we accidentally made number of ignitions on a per grid cell basis, that wouldn't be true. But I can't really see why we would do that. At the moment the number of ignitions is sort of a placeholder anyway. So, yes, I think this is OK, particularly if it cleans things up. " I'm going to assign @bandre-ucar to start testing on Yellowstone if I don't hear anything else by tomorrow. |
|
Assigning @bandre-ucar for testing. |
|
Testing today. |
|
ed - hobart nag : passed |
Merge branch 'rgknox-endrun-maxcohort-weights' In this change-set roughly two objectives are tackled. 1) a wrapper was created to call the CIME shutdown/end-run utitlities. The wrapper is essentially the same wrapper that CLM uses, but we need our own to break dependence. 2) We have various globals in FATES that are dictated by the HLM, and vice versa. I tried to wrangle these variables into FatesInterfaceMod, and give them some functions to set those variables and protect them. Moreover, the new global fates_maxElementsPerSite and fates_maxElementsPerPatch, are calculate based on the maximum requirements for array allocation for FATES restarts. Previously, this was a hard-coded and misleading value. While FATES asks the HLM to allocate a "cohort" array for restart variables, it is really a multi-purpose array, and may be larger than the needs we have to store cohorts. Fixes: #178 and #177 and #144 and #186 Addresses: #141 User interface changes?: No Code review: Testing: rgknox: Test suite: edTest, clm_short_45 Test baseline: 8b2ca7e (PR #176) Test namelist changes: None Test answer changes: b4b with baseline Test summary: all PASS andre Test suite: ed - yellowstone gnu, intel, pgi hobart nag Test baseline: cdb9db7 Test namelist changes: none Test answer: bit for bit Test summary: all tests pass Test suite: clm_short - yellowstone gnu, intel, pgi Test baseline: clm4_5_12_r195 Test namelist changes: none Test answer: bit for bit Test summary: all tests pass
Removed usage of CLM variables from the dynamics portion of the code. 24hour average boundary conditions were added to the bc_in structure. Timing information was moved from udata to FatesGlobals. ldomain(g)%area was removed from spitfire code. The wrapper to litter flux was removed and the contents was added to the dynamics wrapper.
Fixes: none
User interface changes?: none
Code review: requesting @rosiealice among others
Test suite: lawrencium lr3, edTest
Test baseline: d116008
Test namelist changes: none
Test answer changes: none, b4b
Test summary: all PASS, including baseline comparisons