Closed aprokop closed 2 weeks ago
(A few miscellaneous thoughts)
interpolation -> interp geometry -> geom (?) Don't feel strongly about the 2nd but "interp" grew on me and seems to be widely used (akin to "linalg" for linear algebra)
I am wondering whether to put Containers, PriorityQueue, Stack in some (implementation-only) "utils" subcomponent on the same level as "spatial" and co. or if would belong to the Kokkos extensions.
Also we will need to deal with that legacy <ArborX_Exception.hpp>
facility at some point and discuss error handling strategy at large (not here). I am not sure what else would be considered a general purpose utility. Possibly the sorting and permutations things.
Does <ArborX_DetailsTreeNodeLabeling.hpp>
not belong to "cluster"?
The MPI support part potentially could be segregated as well.
Don't feel strongly about the 2nd but "interp" grew on me and seems to be widely used (akin to "linalg" for linear algebra)
Still hate it :) Maybe I'll learn to love it too after some time. And a note that the way we call it in code does not have to be the same as the file structure.
I am wondering whether to put Containers, PriorityQueue, Stack in some (implementation-only) "utils" subcomponent on the same level as "spatial" and co. or if would belong to the Kokkos extensions.
Not a bad idea.
Also we will need to deal with that legacy
<ArborX_Exception.hpp>
facility at some point and discuss error handling strategy at large (not here). I am not sure what else would be considered a general purpose utility. Possibly the sorting and permutations things.
ARBORX_ASSERT
may be the only assert we have that is not disabled with -DNDEBUG
. If I recall correctly, KOKKOS_ASSERT
and assert
are both ignored. I def would like to improve the error handling strategy, it is very inconsistent right now.
Agree with putting sorting to the general purpose. Perhaps, space filling curves too.
Does
<ArborX_DetailsTreeNodeLabeling.hpp>
not belong to "cluster"?
I thought about it, and decided it's not. True, right now it is only being used on MST. But I can see cases where a user uses it for filtering out some traversal paths, or for doing some operations during traversal. Especially, if we introduce some internal node callback. For example, the force calculations in cosmology that accumulate mass data into the internal nodes and then use it based on the angle.
The MPI support part potentially could be segregated as well.
Yes, that sounds like a good idea. It really has little in common with the regular indexes, and is simply a user of those.
An updated version based on the discussion:
src
├── ArborX.hpp
├── ArborX_Config.hpp.in
├── ArborX_Version.hpp.in
├── clustering
│ ├── ArborX_DBSCAN.hpp
│ ├── ArborX_Dendrogram.hpp
│ ├── ArborX_HDBSCAN.hpp
│ ├── ArborX_MinimumSpanningTree.hpp
│ └── details
│ ├── ArborX_DetailsDendrogram.hpp
│ ├── ArborX_DetailsFDBSCAN.hpp
│ ├── ArborX_DetailsFDBSCANDenseBox.hpp
│ ├── ArborX_DetailsMinimumSpanningTree.hpp
│ ├── ArborX_DetailsMutualReachabilityDistance.hpp
│ ├── ArborX_DetailsUnionFind.hpp
│ └── ArborX_DetailsWeightedEdge.hpp
├── distributed
│ ├── ArborX_DistributedTree.hpp
│ └── details
│ ├── ArborX_DetailsDistributedTreeImpl.hpp
│ ├── ArborX_DetailsDistributedTreeNearest.hpp
│ ├── ArborX_DetailsDistributedTreeSpatial.hpp
│ ├── ArborX_DetailsDistributedTreeUtils.hpp
│ ├── ArborX_DetailsDistributor.hpp
├── geometry
│ ├── ArborX_Box.hpp
│ ├── ArborX_DetailsAlgorithms.hpp
│ ├── ArborX_GeometryTraits.hpp
│ ├── ArborX_HyperBox.hpp
│ ├── ArborX_HyperPoint.hpp
│ ├── ArborX_HyperSphere.hpp
│ ├── ArborX_HyperTriangle.hpp
│ ├── ArborX_KDOP.hpp
│ ├── ArborX_Point.hpp
│ ├── ArborX_Ray.hpp
│ └── ArborX_Sphere.hpp
├── interpolation
│ ├── ArborX_InterpMovingLeastSquares.hpp
│ └── details
│ ├── ArborX_InterpDetailsCompactRadialBasisFunction.hpp
│ ├── ArborX_InterpDetailsMovingLeastSquaresCoefficients.hpp
│ ├── ArborX_InterpDetailsPolynomialBasis.hpp
│ └── ArborX_InterpDetailsSymmetricPseudoInverseSVD.hpp
├── kokkos_ext
│ ├── ArborX_DetailsKokkosExtAccessibilityTraits.hpp
│ ├── ArborX_DetailsKokkosExtArithmeticTraits.hpp
│ ├── ArborX_DetailsKokkosExtMinMaxOperations.hpp
│ ├── ArborX_DetailsKokkosExtMinMaxReduce.hpp
│ ├── ArborX_DetailsKokkosExtSort.hpp
│ ├── ArborX_DetailsKokkosExtStdAlgorithms.hpp
│ ├── ArborX_DetailsKokkosExtSwap.hpp
│ ├── ArborX_DetailsKokkosExtVersion.hpp
│ └── ArborX_DetailsKokkosExtViewHelpers.hpp
└── spatial
│ ├── ArborX_BruteForce.hpp
│ ├── ArborX_CrsGraphWrapper.hpp
│ ├── ArborX_LinearBVH.hpp
│ └── details
│ ├── ArborX_AccessTraits.hpp
│ ├── ArborX_AttachIndices.hpp
│ ├── ArborX_Callbacks.hpp
│ ├── ArborX_DetailsBatchedQueries.hpp
│ ├── ArborX_DetailsBruteForceImpl.hpp
│ ├── ArborX_DetailsCartesianGrid.hpp
│ ├── ArborX_DetailsCrsGraphWrapperImpl.hpp
│ ├── ArborX_DetailsExpandHalfToFull.hpp
│ ├── ArborX_DetailsHalfTraversal.hpp
│ ├── ArborX_DetailsHappyTreeFriends.hpp
│ ├── ArborX_DetailsLegacy.hpp
│ ├── ArborX_DetailsNearestBufferProvider.hpp
│ ├── ArborX_DetailsNode.hpp
│ ├── ArborX_DetailsPermutedData.hpp
│ ├── ArborX_DetailsTreeConstruction.hpp
│ ├── ArborX_DetailsTreeNodeLabeling.hpp
│ ├── ArborX_DetailsTreeTraversal.hpp
│ ├── ArborX_DetailsTreeVisualization.hpp
│ ├── ArborX_IndexableGetter.hpp
│ ├── ArborX_NeighborList.hpp
│ ├── ArborX_PairIndexRank.hpp
│ ├── ArborX_PairValueIndex.hpp
│ ├── ArborX_PredicateHelpers.hpp
│ ├── ArborX_Predicates.hpp
│ └── ArborX_TraversalPolicy.hpp
└── utils
├── ArborX_DetailsContainers.hpp
├── ArborX_DetailsHeap.hpp
├── ArborX_DetailsMortonCode.hpp
├── ArborX_DetailsOperatorFunctionObjects.hpp
├── ArborX_DetailsPriorityQueue.hpp
├── ArborX_DetailsSortUtils.hpp
├── ArborX_DetailsStack.hpp
├── ArborX_DetailsUtils.hpp
├── ArborX_Exception.hpp
└── ArborX_SpaceFillingCurves.hpp
interpolation -> interp
numpy.interp
, scipy.interpolation
Current:
Proposed:
Not 100% sure what to do with tests. I would not want to duplicate the infrastructure.