-
Notifications
You must be signed in to change notification settings - Fork 4
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
Have SZ, nx_loc, n_groups etc. accessible "globally" #77
Comments
I agree, there is a bit duplication in some variables and its better to clean them up sooner than later. Lets try to come up some sensible notation here and then implementing it will be easy. I think the most important point is having a clear distinction between padded dimensions and actual domain dimensions. This will help for a smooth transition from periodic to non-periodic BCs. Currently in both backends we use For the actual local domain size, I think Also,
|
I agree with getting rid of Happy with About Just a thought but, nx/ny/nz, n_groups, and SZ define dimensions of the fields. Could they be stored in That way any loop working on a particular field will always work with the same loop ranges (field%n_groups, field%n and field%SZ) and these values will always be 'at hand' without passing |
solved by #95 |
At the moment all the variables that define block sizes are defined in various places and sometimes duplicated over multiple structures. For example,
backend_t
hasnx_loc
,ny_loc
,ny_loc
, but so hasbackend_t%xdirps%n
etc.SZ
is accessed inm_omp_common
orm_cuda_common
depending on the backend, meaning we can't access it outside the backend functions (unless being passed as argument from there etc.).It would be good to have a single consistent way of accessing all of these variable. It will also reduce the number of arguments needed to be passed around.
The text was updated successfully, but these errors were encountered: