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

Memory ordering solver is not optimal for any form of 3D radiation #4

Open
Chiil opened this issue Feb 4, 2021 · 0 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@Chiil
Copy link
Member

Chiil commented Feb 4, 2021

The solver is executed in blocks of 16 n_col_block (hard coded value resulting from performance tuning in CPU version, see for instance in src_test/Radiation_solve.cxx:378) columns and then for all layers and gpoints. This setup is chosen, because in the RRTMGP part of the code, ngpt is the inner dimension, in order to have the most efficient table lookups. In the end of the RRTMGP solver the data is transposed, in order to make ngpt the outermost dimension (for instance src/Gas_optics_rrtmgp.cpp:1280). This means that the code constantly works with fields that are of the order of ngpt*nlay*n_col_block in size.

For a solver that could be extended to 3D (slanted column, n-stream, ray tracing) it is essential to have the full 3D field in memory, so ngpt should be the outer dimension under all conditions. In this case, the full solver could be run per gpoint.

@Chiil Chiil added the enhancement New feature or request label Feb 4, 2021
@Chiil Chiil self-assigned this Feb 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant