Conversation
b12e871 to
090441d
Compare
67e6434 to
bb07d04
Compare
joewallwork
left a comment
There was a problem hiding this comment.
Thanks for this @TomMelt. Here's some initial feedback. I haven't checked all of the logic but let me know if there's anything in particular you want checking.
core/src/include/Halo.hpp
Outdated
| template <int N> Halo(DGVectorHolder<N>& dgvh) | ||
| { | ||
| m_numComps = N; | ||
| setSpatialDims(); | ||
| intializeHaloMetadata(); | ||
| } | ||
|
|
||
| /*! | ||
| * @brief Constructs a halo object from DGVector | ||
| * @param dgv DGVector object to create halo from | ||
| */ | ||
| template <int N> Halo(DGVector<N>& dgv) | ||
| { | ||
| m_numComps = N; | ||
| isVertex = false; | ||
| setSpatialDims(); | ||
| intializeHaloMetadata(); | ||
| } | ||
|
|
||
| /*! | ||
| * @brief Constructs a halo object from CGVector | ||
| * @param cgv CGVector object to create halo from | ||
| */ | ||
| template <int N> Halo(CGVector<N>& cgv) | ||
| { | ||
| m_numComps = 1; | ||
| isCG = true; | ||
| CGdegree = N; | ||
| nCells = CGdegree; | ||
| setSpatialDims(); | ||
| intializeHaloMetadata(); |
There was a problem hiding this comment.
In none of these cases do the constructors depend on their argument, right? The only information that's being used is the value of N and the type. So do we actually need to provide dgv, dgvh, or cgv as arguments?
There was a problem hiding this comment.
I think we do, because we need to templated N from dgv and dgvh.
You are right that Halo(DGVectorHolder<N>& dgvh) and Halo(DGVector<N>& dgv) are essentially the same. But Halo(ModelArray& ma) and Halo(CGVector<N>& cgv) set different member variables from dgv.
What I could do however, is change Halo(DGVectorHolder<N>& dgvh) to call Halo(DGVector<N>& dgv) with static_cast<DGVector<DGadvection>&>() like we do in dynamics:
nextsimdg/dynamics/src/include/BrittleCGDynamicsKernel.hpp
Lines 131 to 134 in 87dadeb
There was a problem hiding this comment.
There seems to be quite a lot of implementation in this header file. Might it be better to separate it out into core/src/Halo.cpp?
There was a problem hiding this comment.
Agreed. Function definitions should go in a source file if possible. Exceptions are (public) template functions which have to be defined in the header and maybe one-liners.
There was a problem hiding this comment.
Thanks @joewallwork and @Thanduriel . I have split the implementation as suggested and I also tidied up a bit.
- Split implementation out from
Halo.hppintocore/src/Halo.cpp - Moved implementation of non-templated functions to
core/src/Halo.cpp - Made the following functions private:
setSpatialDims()intializeHaloMetadata()sendBufferPositions()sourceToSendBuffer()recvBufferPositions()recvBufferToTarget()recvBufferToTarget()transposeCorners()populateTarget()
See commit c213634
6af5840 to
eb26a81
Compare
b8507c9 to
b693869
Compare
- Split implementation out from `Halo.hpp` into `core/src/Halo.cpp` - Moved implementation of non-templated functions to `core/src/Halo.cpp` - Added `Halo.cpp` to `core/src/CMakeLists.txt` - Made the following functions private: - `setSpatialDims()` - `intializeHaloMetadata()` - `sendBufferPositions()` - `sourceToSendBuffer()` - `recvBufferPositions()` - `recvBufferToTarget()` - `recvBufferToTarget()` - `transposeCorners()` - `populateTarget()` All tests pass: `ctest` (6/6 tests passed)
e4d3e65 to
c213634
Compare
Thanduriel
left a comment
There was a problem hiding this comment.
I have one alternative suggestion for the shorter enum types but you decide if you want to make the change. From my side the code is ready for merge.
joewallwork
left a comment
There was a problem hiding this comment.
This is great, thanks @TomMelt. I have a few small requests but I think it's otherwise good to go!
| * │ │x│x│ │ (empty) = unused data in DGVector | ||
| * └─┴─┴─┴─┘ | ||
| */ | ||
| template <typename T> void exchangeHalos(T& target) |
There was a problem hiding this comment.
Please could you add a docstring for this function?
| * | ||
| * Halo supports the main data structures of NextSim e.g., ModelArray, DGVector and CGVector. | ||
| * | ||
| * The halos are exchange via one-sided MPI communication using RMA. |
There was a problem hiding this comment.
Perhaps spell out RMA here for clarity.
|
|
||
| void Halo::populateRecvBuffers() | ||
| { | ||
|
|
Add corner neighbours into halo exchange logic
Task List
Change Description
This PR has the following key changes:
CGVectorandDGVectorHolderexchange (this is required for corners and edges)Test Description
HaloExchangePB_test.cppHaloExchangeCB_test.cppcreates test data for all the array types:HFieldVertexFieldDGFieldDGVectorCGVectorI modified the previous version, so that the model data are created in such a way that the value of each cell can be calculated based on its indices. Therefore we can check after exchange that all of the cells have been exchanged successfully. This also now allows us to change the number of ranks arbitrarily (assuming you also provide the appropriate
partition_metadatafile.ModelMetadataCB_test.cppandModelMetadataPB_test.cppSmall modifications have been made to the periodic and closed boundary
ModelMetadatatests.The changes now add the additional corner neighbour metadata and check that it is ready correctly.
partition_metadata_3_cb.cdlandpartition_metadata_3_pb.cdlThese files are now generated at compile time by running the
decomptool on a new filehalo_test_mask.cdl. This is in line with similar changes introduced by @joewallwork on the XIOS tests.Other Details
domain_decopgit commit has now been bumped to the latest version on main. This version of the decomp tool contains the corner neighbour metadata.Further work