optimad / bitpit

Open source library for scientific HPC
http://optimad.github.io/bitpit/
GNU Lesser General Public License v3.0
117 stars 34 forks source link

patchkernel: improve adaption/partitioning tracking #370

Open andrea-iob opened 1 year ago

andrea-iob commented 1 year ago

Adaption/partitioning tracking is extended also to vertices and interfaces. However, tracking of vertices and interfaces offers only a limited set of information.

During adaption, information available for tracking purposes are the following:

During partitioning, information available on the sender side for tracking purposes are the following:

During partitioning, information available on the receiver side for tracking purposes are the following:

andrea-iob commented 1 year ago

Test failures seems related to problems with travis; pull requests #371 and #372 contain also these changes and there the tests pass just fine.

edoardolombardi commented 1 year ago

The pull seems not working for vertices tracking. The adaption info returned for entity VERTEX are empty.

You can see with following modifications to test_volunstructured_parallel_00001 as following (this code chunk at the place of line 523):

` std::vector adaptionInfo = patch_3D->partition(cellRanks, true, true);

log::cout() << "adaption info size: " << adaptionInfo.size() << std::endl;

for (auto & info : adaptionInfo) {
    if (info.entity == bitpit::adaption::Entity::ENTITY_CELL) {
        log::cout() << "cell info previous: " << info.previous << std::endl;
        log::cout() << "cell info current: " << info.current << std::endl;
    }
    else if (info.entity == bitpit::adaption::Entity::ENTITY_VERTEX) {
        log::cout() << "vertex info previous: " << info.previous << std::endl;
        log::cout() << "vertex info current: " << info.current << std::endl;
    }

}

` The previous/current vectors in case of ENTITY_VERTEX adaption entity are empty. But maybe I'm doing something wrong in the usage...

@andrea-iob could you add in the pull a test or an example of usage of the tracking results, please? For both purposes, to test the implementation (at least that there are no empty structures neither segmentation fault, or better if a predefined partitioning is reached) and to help the usage.

I don't know where is the best place and the best way to explain it, but could you also add some comments to the documentation or of the adaption info structures (completely missing) or to the partition methods to explain what the returning objects mean, please? What are the current ids, the previous ones for instance, where the user can find info on ghost cells/vertices/interfaces, etc. Practically, I think that it should be enough explaining where each one of the info that you listed in the description of the pull can be retrieved.

Thanks

andrea-iob commented 1 year ago

Tracking vertex send/receive during partitioning is more tricky than expected. The image represent a 2x2 mesh before (left) and after (right) the bottom left cell has been send from process #0 to process #2.

vertex_tracking

Cell exchange involves ranks #⁠0 and #⁠2, but after the cell have been send there are some vertices that are now owned by process #⁠1 (the owner of a vertex is the process with the lowest rank). The tracking should than report that those vertices have been sent to process #⁠1 from process #⁠0. I'm not sure how I can get that information in the partitioning prepare stage (this is when vertex data to be send should be collected).

The best solution would be to void tracking data exchange for vertices and relay on cell exchange to communicate vertex data.

        for (const auto &adaptionInfo : updateData) {
            if (adaptionInfo.entity != adaption::ENTITY_CELL) {
                continue;
            }

            int rank = adaptionInfo.rank;
            adaption::Type adaptionType = adaptionInfo.type;
            if (adaptionType == adaption::TYPE_PARTITION_SEND) {
                const std::vector<long> &cellsToSend = adaptionInfo.previous;
                std::vector<long> verticesToSend = patch->getOrderedCellsVertices(cellsToSend, true, true);

                // Start vertex communications
                ...              
            }
        }

I've already modified the branch to allow that, after some more tests I'll push it.