-
Notifications
You must be signed in to change notification settings - Fork 64
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
Require variable dimensions in argument list? #197
Comments
I think yes, most schemes would have this anyway because of performance considerations:
Thus it seems reasonable to me to make this a requirement. |
Just to give a different point of view, Fortran has not required that users pass dimensions for their arrays for quite awhile now. With the introduction of allocatable arrays (again a long time ago), users have been allocating arrays to exact sizes and not needed to bother with the exact dimensionality of their arrays. They've been using ":" in both declarations and within the code itself. While I agree that the metadata needs to specify the dimension names within the dimensions field, it seems like a burden (and a step backwards) to require that the dimensions be required to be passed as arguments. I imagined that the CPF could keep a master list of dimension names and retrieve the values from it. I am seeing with chemistry, that there are a number of arrays which are passed through the CPF which have unique (sometimes hardwired) dimensions. In all of these cases, the operations are over the entire dimensions, so the exact sizes are irrelevant and are not values which are being passed. I am unaware of the performance consideration that Dom says exists. Is this just that the array has been declared larger than it needed to be, or is there some other performance enhancement which occurs with explicitly declared arrays? Unless there is a strong reason for requiring dimensions to be passed, I am not in favor of making this a requirement. |
@climbfuji
and
On the other hand, the first form bypasses array size checks. This can be troublesome, especially for multi-dimensional arrays and for debugging. Do you have a (simple) test that shows a performance difference? |
I have some questions about your post:
The Framework does not have any master list. It collects dimension information from standard names in
How are the operations over "the entire dimensions" being performed? Using array syntax? In a loop? If the answer is a loop, where is the loop size coming from? |
As long as "someone" does not need to be the host model, but can be a lower level scheme, that is fine. I guess that's what I meant by a "master list". As long as one scheme's metadata defines the dimension, then other schemes can use it, then I'm happy.
Right now, they are being "use"d from the routines where they are declared. Obviously that will need to change. If I needed the size I would have determined the size using the Fortran intrinsic. |
Short answer: no, I don't. I was thinking that the first version would be more performant, but this is probably only true if the compiler knows what levs is (e.g. because it is set as a parameter at compile time), so that's probably not very useful. |
Here is an update: |
We do not require dimension variables to be part of a CCPP scheme argument list. |
In the new metadata convention, array variables must document their dimensions. For example:
Should the framework require that dimension variables (
vertical_layer_dimension
in this case) be included in the same metadata table (i.e., also be an argument to the scheme)?The text was updated successfully, but these errors were encountered: