Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Needed: check on maxCohortsPerPatch #178

Closed
rgknox opened this issue Jan 18, 2017 · 0 comments
Closed

Needed: check on maxCohortsPerPatch #178

rgknox opened this issue Jan 18, 2017 · 0 comments
Labels
enhancement

Comments

@rgknox
Copy link
Contributor

rgknox commented Jan 18, 2017

Summary of Issue:

The EDTypesMod global "maxCohortsPerPatch" defines the allocated space of many key arrays used in restart IO.

Example 1: Its value, combined with maxPatchesPerCol, define cohorts_per_col, which is sent to the HLM early on in the initialization sequence to define the cohort dimension in restart files.

Example 2: We use the cohort dimension (defined by maxCohortsPerPatch) to store various multi-dimension arrays at the patch and site scale. In these cases, the total number of elements in these multi-dimensional arrays must be less than maxPatchesPerCol.

However, we do not have any checks to make sure that maxPatchesPerCol is greater than or equal to these multidimensional array element sizes. We also do not calculate cohorts_per_col as a dependent variable based on maxPatchesPerCOl and maxCohortsPerPatch.

We have skirted these problems for the time being, as we have not changed the number of PFTs in our simulations from a hard coded value of 2. Once we break from this, we will have many failures with restarts.
@rgknox rgknox mentioned this issue Jan 25, 2017
Merged
bandre-ucar added a commit that referenced this issue Mar 6, 2017
@bandre-ucar
Interface: endrun and cleaning of fates<->hlm globals
b0bceb0 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@rgknox