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

increase or remove maxpft #265

Open
rgknox opened this issue Aug 29, 2017 · 4 comments
Open

increase or remove maxpft #265

rgknox opened this issue Aug 29, 2017 · 4 comments
Assignees

Comments

@rgknox
Copy link
Contributor

rgknox commented Aug 29, 2017

FATES has a dynamic number of PFTs, defined as numpft. This is used for various allocations, most notably the history and restart files.

But we do still use a "maxpft" in some cases, kind of like a scratch space. This is a constant parameter that is used to statically allocate memory. The maxpft parameter should be set to an upper reasonable limit of what numpft could potentially be. Its current size is 10.

We should either increase that limit from 10, to something like 20, as @jenniferholm has already run into scenarios where she needs a higher upper limit. Or, I could put the time into removing the static allocations and replacing with completely dynamic allocations. Option 1 is super trivial, option 2 is not trivial but not onerous.

@rgknox rgknox self-assigned this Aug 29, 2017
@jenniferholm
Copy link
Contributor

jenniferholm commented Aug 29, 2017

I say just stick with option 1 and increase the limit of "maxpft" to 20, well at least for now.

However, there could be times in the future (especially when we get to more trait based pfts, or large PDF distributions of pfts) that we need something like 100s pfts. But I think this capability is far off in the future.

@rosiealice
Copy link
Contributor

Is this something we can change at any point, or does it affect the interface? In the long run it'd be better to have the capability to run with 'n' PFTs, just because this is one of the core benefits of FATES for the broader user community. It would be better to be able to do it than to say ' you can do this, in theory, except when you can't'... ;o)

@rgknox
Copy link
Contributor Author

rgknox commented Aug 29, 2017

This doesn't affect the interface.
I think its worth putting in a little time to get rid of maxpft, following your argument @rosiealice.

@ckoven
Copy link
Contributor

ckoven commented Aug 29, 2017

As a first step, it might be interesting to know how many PFTs one can actually run before the thing runs out of memory and/or becomes impractically slow. I'm intrigued by the result that with the current version of the PFT file, if you give it identical PFT descriptions, the PFTs don't diverge in their dynamics at all for at least the first 25 years or so; I'd have expected chaotic dynamics to kick in long before that. But it suggests that one could do the experiment of running with 4,8,16,... identical PFTs, reducing initd accordingly to get identical results, and see where the software starts to break down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants