[Core][MPI] Adding SpatialSearchResultContainer and SpatialSearchResultContainerMap

[loumalouomega]

📝 Description

This PR introduces a new class named SpatialSearchResultContainer and SpatialSearchResultContainerMap. The class provides storage and operations related to spatial search results. This is a transition PR to finally give support for MPI search using GeometricalObjectBins.

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)
4. A map of distances from the results (local)
5. A vector of distances from results (global)

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 SpatialSearchResultContainerMap class stores an unordered map of SpatialSearchResultContainer, using an integer as hash. The hash is computed from the point coordinates which we are computing the results.

This commit seems to be a significant enhancement, providing a new means of handling and manipulating spatial search results in the Kratos library.

🆕 Changelog

• The spatial_search_result_container.cpp and spatial_search_result_container.h files have been added, representing the implementation and header for the SpatialSearchResultContainer and SpatialSearchResultContainerMap classes.
• Expose to python SpatialSearchResultContainer and SpatialSearchResultContainerMap
• Adding tests for SpatialSearchResultContainer and SpatialSearchResultContainerMap
• Update python interface and redefine tests with new interface
• Adding missing == operator See [Core] Added equality operator overload to GlobalPointer class in global_pointer.h #11206
• Adding test for spatial search result See [Core] Adding test for spatial search result #11207
• Changes from [Core] Activate check after recent merge in == operator in SpatialSearchResult #11221

[loumalouomega]

Ready @pooyan-dadvand

[loumalouomega]

@roigcarlo do you want to meet to advance with the review of this?

[pooyan-dadvand]

@loumalouomega Thanks for the implementation and large effort to make the spatial search MPI parallel.

Before going into the details of the implementation I would like to put here my comments (after talking directly with you about the global design)

1. To my understanding you are changing the simple std::vector<ResultType>& rResults in the search interface with a container which gives more info. Nevertheless, the change in how you are storing them (separating the pointers and distances) would make more difficult having a loop over results and work with the found object and distance:

for(auto& result : search_results){
    auto& geometry = result.Get()->GetGeometry();
    double distance = result.GetDistance();
    if(distance....)
}

2. Using the same container for the SearchNearest implies an allocation of the array (only for 1 element) which can be a noticeable performance issue.
3. In the MPI version, having a specialized communicator would be a good alternative approach.
4. Using point coordinates as the hash for the map would be dangerous. (We may use the pointer to the point as the reference?)
5. We should add new interfaces to the spatial containers for working with several queries at once. (Simply because it is very inefficient to do one by one query in MPI. This leads to have Map container variant but we should revisit that interface again.

@roigcarlo and @jcotela I would like to hear your design comments and concerns.

[loumalouomega]

Closing as included in #11719