Neighbourhood diagonal #76
Conversation
|
@niravshah241 thanks for drafting this PR. I know that it is draft stage but draft PRs still shouldn't contain CMake build files. Please remove these as discussed last meeting. Please only commit changes for relevant source files. |
…pdated to corner_neighbour
…inghbour logic in discover_neighbours
There was a problem hiding this comment.
@niravshah241 as a rule, I would generally just remove this change. It's just formatting. Unless it's required by the linter (which I dont think it is).
…c neighbour tests in integration still need to be fixed, More tests test_3 and test_4 added for corner neighbours, test_1 and test_2 reference files updated to include details on corner neighbour
|
Pending tasks:
|
* update tests to work with main branch * update Partitioner to use new halo_send/recv approach for edges
…regarding calling is_corner_neighbour is added in halo_corner_start
… exchange logic comment rephrasing
| } | ||
| } | ||
|
|
||
| bool Partitioner::is_corner_neighbour( |
There was a problem hiding this comment.
Add some documentation here to explain how this works?
| const Domain d1, const Domain d2, const Vertex vertex, const bool is_px, const bool is_py) | ||
| { | ||
| if (vertex == TOP_LEFT) { | ||
| // is_px and is_py is not updatd ath moment as periodic boundaries are not considered. |
| return start; | ||
| } | ||
|
|
||
| int Partitioner::halo_corner_start(const Domain d1, const Domain d2, const Vertex vertex) |
There was a problem hiding this comment.
Make clear that a pre-condition of using this function is that is_corner_neighbour is true.
Partitioner.cpp
Outdated
| // is_px and is_py is not updatd ath moment as periodic boundaries are not considered. | ||
| // Check if TOP Left neighbour i.e., |
There was a problem hiding this comment.
Some documentation on what is_px and is_py are for is needed.
I don't understand why the TOP_LEFT case doesn't look at either is_py or is_px but all the other cases do... why would something be special here?
Once the domain is divided across different MPI ranks, the rank corresponding to the neighbour of a given subdomain in a given direction needs to be identified. Currently the functionality is implemented to identify neighbours in TOP, RIGHT, BOTTOM and LEFT direction which share a common edge with the given subdomain. This Draft PR aims to add functionality to identify neighbours in TOP_RIGHT, BOTTOM_RIGHT, BOTTOM_LEFT and TOP_LEFT corners.
Specifically, the changes include: