update doc files #118
update doc files #118
Conversation
There was a problem hiding this comment.
Thanks @aekiss LGTM! Only a comment on the selection of block_size_x, block_size_y, and max_blocks.
| distribution_type = "cartesian" | ||
| distribution_wght = "latitude" | ||
| maskhalo_bound = .true. | ||
| maskhalo_dyn = .true. | ||
| maskhalo_remap = .true. | ||
| max_blocks = 10 | ||
| max_blocks = 15 |
There was a problem hiding this comment.
| max_blocks = 15 | |
| max_blocks = -1 |
In the latest 025deg_jra55do_ryf, max_blocks has been set to -1 to allow the code to automatically determine the optimal value.
Line 78 in f4b2d1e
I can quickly update the 1deg config.
| block_size_x = 15 | ||
| block_size_y = 20 |
There was a problem hiding this comment.
As was discussed in COSIMA/access-om3#214 (comment) and cice docs, It is suggested that max_blocks be set in the range of 3-8 blocks per processor.
| block_size_x = 15 | |
| block_size_y = 20 | |
| block_size_x = 30 | |
| block_size_y = 40 |
With the updated block_size_x and block_size_y, max_blocks is determined to be 8, which suits the recommendation from the cice docs.
There was a problem hiding this comment.
With the slender distributions block_size_x should equal nx_global/nprocs i.e. 360/24 = 15. Which is why these block sizes are set as they are at the moment
There was a problem hiding this comment.
Thanks @anton-seaice. So for slenderX1, the block size in the y direction should be 300 instead of 20, right? This is because there is only one processor in the y direction, and it needs to handle all 300 grid points.
There was a problem hiding this comment.
You could try that. That would mean there is 1 block per processor, which means you couldn't eliminate any blocks which are entirely land. I am not sure how it could impact inter-process communication ? I suspect the performance will be about the same as the current configuration ?
There was a problem hiding this comment.
I dont get it. If that’s the case, why does block_size_x equal nx_global / nprocs, but block_size_y is calculated differently?
There was a problem hiding this comment.
Its just kind of by definition, you can have multiple blocks in Y but not X. Each color is a different processor:
|
This PR is just to update the documentation to match the config, so how about we merge this, then explore changes to the config as a separate issue? It's easy to rerun |
contributes to COSIMA/access-om3#224