-
Notifications
You must be signed in to change notification settings - Fork 92
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
Comments
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. |
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) |
This doesn't affect the interface. |
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. |
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.
The text was updated successfully, but these errors were encountered: