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.

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

SP restart crash #1182

Closed
rgknox opened this issue Mar 30, 2024 · 1 comment · Fixed by #1189
Closed

SP restart crash #1182

rgknox opened this issue Mar 30, 2024 · 1 comment · Fixed by #1189

Comments

@rgknox
Copy link
Contributor

rgknox commented Mar 30, 2024

We do some reading/writing of restart variables using a loop that spans:
numpft x nlevsclass x n_term_mort_types

In non SP runs, we most likely allocate enough memory because we typically run with more cohorts per gridcell than the product of these three terms, but in SP mode that is not likely true.

Here is an example of traversing that loop.

https://github.com/NGEET/fates/blob/sci.1.72.6_api.34.0.0/main/FatesRestartInterfaceMod.F90#L2199-L2217

I believe the solution is to increase the allocation here by adding in n_term_mort_types to the product with nlevsclass and numpft:

https://github.com/NGEET/fates/blob/sci.1.72.6_api.34.0.0/main/FatesInterfaceMod.F90#L879-L880

to be:

fates_maxElementsPerSite = max(fates_maxPatchesPerSite * fates_maxElementsPerPatch, &
              numWatermem*numpft, num_vegtemp_mem, num_elements, nlevsclass*numpft*n_term_mort_types)

I'm testing now.

@rgknox
Copy link
Contributor Author

rgknox commented Apr 8, 2024

Noting that after some discussion, @ckoven thought it would be better to not report these diagnostics at all, since they are irrelevant with SP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
1 participant