[Core][MPI] Adding SpatialSearchResultContainer/SpatialSearchResultContainerVector and SearchWrapper (v.4.5)

[loumalouomega]

📝 Description

#11416 + addressed comments

This PR introduces a new class named SpatialSearchResultContainer, SpatialSearchResultContainerVector as well as SearchWrapper. The two first classes provides storage and operations related to spatial search results. In addition SearchWrapper class implements an interface for serial/MPI search for different search objects, in current PR adding GeometricalObjectBins and the available trees.

The SpatialSearchResultContainer class stores:

1. Local pointers of results (in a PointerVectorSet)
2. Global pointers (empty if not synchronized)
3. GlobalPointerCommunicator pointer (to synchronize the global pointers)

The class includes functions such as, SynchronizeAll, HasResult, GetResultIndices, AddResult... The interesting part is that integrates a global pointer communicator, so it is possible to calculate anything passing a functor. The most common operations required are already implemented: GetResultShapeFunctions, GetResultIndices and GetResultCoordinates,

The SynchronizeAll method synchronizes the container between partitions. The AddResult method adds a result to the local pointers. There is a push_back which does the same.

The SpatialSearchResultContainerVector class stores a std::vector of SpatialSearchResultContainer pointers. In the SearchWrapper class the index of the vector corresponds with the node id when using nodes and just a counter when simply searching.

Considering general data communicator instead of sub data communicator

TODO: Using coloring utilities instead of manual coloring

🆕 Changelog

• The spatial_search_result_container.cpp , spatial_search_result_container.hm spatial_search_result_container_vector.cpp and spatial_search_result_container_vector.h files have been added, representing the implementation and header for the SpatialSearchResultContainer and SpatialSearchResultContainerVector classes.
• Expose to python SpatialSearchResultContainer and SpatialSearchResultContainerVector
• Adding tests for SpatialSearchResultContainer and SpatialSearchResultContainerVector
• Update python interface and redefine tests with new interface
• Adding SearchWrapper class, currently just implemented GeometricalObjectBins.
• Adding tests for SearchWrapper.
• Changes from [Core] Unify SearchUtilities #11710
• Changes from [Core][MPI] Adding MinLocAll and MaxLocAll to DataCommunicator #11712
• Changes from [Core] Separate PointObject in different file #11725
• Changes from [Core] Defining GetBoundingBox in Tree class. Plus adding documentation #11730
• Changes from [Core] Defines ObjectType and PointType in GeometricalObjectsBins #11731
• Changes from [Core] Adding minor definition for ObjectType for PointObject #11735
• Changes from [Core] Adding GetObjectType and define ObjectType in Tree #11737
• Changes from [Core] Moving GetObjectType in tree.h #11739
• Changes from [Core] Defining bounding box and ObjectType in DynamicBins #11741
• Changes from [Core] Defining distance in SearchInRadius in GeometricalObjectBins #11754
• Changes from [Core] Add SetRank method to GlobalPointer + documentation #11762
• Changes from [Core] Add GetDataCommunicator to GlobalPointerCommunicator #11794
• Changes from [Core] Adding SynchronizePointsWithBoundingBox method #11877
• Changes from [Core] Missing & in Get method in SpatialSearchResult #12002
• Changes from [Core] Fix BB check #12419
• Changes from [Core] Refactor search_utilities.h to handle negative tolerance values. Actual fix from 12419 #12430
• Changes from [Core] Some minor transitions changes from #11719 #13900
• Changes from [Core] Add methods to compute bounding boxes with tolerance to SearchUtilities #13929
• Update search utilities
• Update the SpatialSearchResultContainer adding SpatialSearchCommunicator enum
• Update the SpatialSearchResultContainerVector adding SpatialSearchCommunicator enum
• Update the SearchWrapper consistently
• Update python exposition

[RiccardoRossi]

just to be sure:

the data_communicator changes being reviewed in a different PR, am i correct?

[loumalouomega]

#11712

[RiccardoRossi]

unimportant question (just ignore if you feel) but, isn't there a vector version of this? i mean one that considers the vector of components instead of each component separately

[loumalouomega]

I don't know, if I can simplify the code that would be welcomed

[RiccardoRossi]

why do you pass the "SyncronizeResults" flag to the serial version? in that case it can only be in sync

[loumalouomega]

Let me check if I can simplify code, originally this was supposed to be a derived class and when refactored the code maybe I copy pasted to much

[RiccardoRossi]

I have the impression that this is really not ready for prime time.

@loumalouomega can we have a call to speak about this ?

[loumalouomega]

After all PR are merged, this is ready for final review

[loumalouomega]

@pooyan-dadvand @RiccardoRossi I removed the shared_ptr

leaving the review to @pooyan

[loumalouomega]

@RiccardoRossi you mentioned a random pooyan instead of @pooyan-dadvand

[roigcarlo]

Aside for the fact that I still find the search_wrapper odd, I see no other problem.

@RiccardoRossi for me this is ok to merge...

[loumalouomega]

I think this is definetively ready @pooyan-dadvand

[loumalouomega]

@pooyan-dadvand I reverted this, because I didn't remember, but search are locals, for performance reasons, and it is not possible to use a syncronous data communicator inside the search, otherwise it gets stuck, and thats why the last CI after 9726a34 was failing.

This is far more efficient than performing a global search with all partitions at once.