Pure tidy up to standardize style of use and remove empty and uneeded
blocks.

This is a pure CMake variable used to activate the benchmarking
component of VecGeom's testing suite. It's never used as a preprocessor
symbol in library code, with one remaining use converted to use the
VECGEOM_CUDA symbol as elsewhere.

This symbol is no longer transmitted by compiler flag.

Version pulled in from AliSW GitHub is >5 years old and no longer
configures/compiles with current Geant4, ROOT, CLHEP.

The change implements the VNavigator::Relocate interface and the auxiliary helper methods needed for that, working on both host/device.

Function annotation as host device as needed. Implement the Instance method for the GPU case.

Simplify the current logic which uses the mother volume convexity to prioritize daughter checks. This approach is not always justified because it may increase the search range for daughter candidates. The current approach is conservative and uses the distance to mother first to limit the search distance for daughters, only if there are daughters. The check for daughters at this point spares extra checks in the derived navigators, which in the case of BVH was even generating a crash.

This leads to warnings with Clang:

VecGeom/VecGeom/base/robin_hood.h:1224:40:
  warning: builtin __has_trivial_copy is deprecated;
  use __is_trivially_copyable instead [-Wdeprecated-builtins]
    Cloner<unordered_map, IsFlatMap && ROBIN_HOOD_IS_TRIVIALLY_COPYABLE(Node)>()(o, *this);
                                       ^
VecGeom/VecGeom/base/robin_hood.h:158:47:
  note: expanded from macro 'ROBIN_HOOD_IS_TRIVIALLY_COPYABLE'
  #define ROBIN_HOOD_IS_TRIVIALLY_COPYABLE(...) __has_trivial_copy(__VA_ARGS__)

VariableSizeObj returns a pointer allocated with new char[n], so it
needs to be deleted in the same way:

VecGeom/test/core/BitSetTest.cpp: In function ‘void BitSetTest()’:
VecGeom/test/core/BitSetTest.cpp:90:10: warning: ‘void operator delete(void*, std::size_t)’
called on pointer returned from a mismatched allocation function [-Wmismatched-new-delete]
   90 |   delete s;
      |          ^
In file included from VecGeom/VecGeom/base/BitSet.h:11,
                 from VecGeom/test/core/BitSetTest.cpp:1:
In static member function
‘static Cont* vecgeom::VariableSizeObjectInterface<Cont, V>::MakeInstance(size_t, const T& ...)
  [with T = {long unsigned int}; Cont = vecgeom::BitSet; V = unsigned char]’,
  inlined from ‘static vecgeom::BitSet* vecgeom::BitSet::MakeInstance(size_t)’
    at VecGeom/VecGeom/base/BitSet.h:255:32,
  inlined from ‘void BitSetTest()’
    at VecGeom/test/core/BitSetTest.cpp:58:35:
    VecGeom/VecGeom/base/VariableSizeObj.h:95:21:
    note: returned from ‘void* operator new [](std::size_t)’
  95 |     char *ptr     = new char[needed];
     |                     ^~~~~~~~~~~~~~~~

from VecGeom/test/core/testVectorSafety.cpp:13:
In static member function
‘static Cont* vecgeom::VariableSizeObjectInterface<Cont, V>::MakeInstance(size_t, const T& ...)
[with T = {}; Cont = vecgeom::cxx::NavStatePath; V = long unsigned int]’, inlined from
‘static vecgeom::cxx::NavStatePath* vecgeom::cxx::NavStatePath::MakeInstance(int)’
  at VecGeom/VecGeom/navigation/NavStatePath.h:218:32, inlined from
  ‘void testVectorNavigator(const vecgeom::cxx::VPlacedVolume*)’
    at VecGeom/test/core/testVectorSafety.cpp:121:57:
      VecGeom/VecGeom/base/VariableSizeObj.h:95:21:
      note: returned from ‘void* operator new [](std::size_t)’
   95 |     char *ptr     = new char[needed];
      |                     ^~~~~~~~~~~~~~~~

Calling copy() with an SOA3D of size zero leads to calling memmove
with a null pointer when it expects non-null arguments:

... inlined from ‘vecgeom::cxx::AOS3D<T>::AOS3D(size_t) [with T = double]’
  at VecGeom/VecGeom/base/AOS3D.h:148:10,
    inlined from ‘void SizeTest() [with T = double; ContainerType = vecgeom::cxx::AOS3D]’
      at VecGeom/test/core/ContainerTest.cpp:9:20:
      /usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/bits/stl_algobase.h:431:30:
      warning: argument 1 null where non-null expected [-Wnonnull]
  431 |             __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
      |             ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/12/include/g++-v12/bits/stl_algobase.h:431:30:
  note: in a call to built-in function
    ‘void* __builtin_memmove(void*, const void*, long unsigned int)’

This may also happen when AOS3D::reserve(0) is called, or when creating
a zero-sized container by calling the constructor with a size of 0.

* Fixed namespace warning

* Added protection when using BVH navigation in leaf volumes

* Updated location for test files download.

As of now, all "dynamically sized" shapes such as polyhedra, polycones,
and extruded solids allocate memory in kernels. This is problematic as
CUDA only has a very limited amount of scratch space for malloc / new.
Until the "transfer code" for these types of shapes is fixed, add the
function CudaDeviceSetHeapLimit similar to CudaDeviceSetStackLimit to
let VecGeom clients work around this problem.

CUDA has only a very limited amount of scratch space for malloc / new.
Having many polyhedra exhausted that space, for example when trying to
transfer the Phase2 preview geometry of CMS to the GPU.

The previous commit 5c505fb4 "Ensure that transformation data in nav table is stored aligned" did not update the navigation index table size correctly. This lead to out of bounds access, because the allocated buffer for the table was not large enough. Commit b99894e0 fixed an assertion triggerd by this bug, but did not fix the issue for all code paths.

Jonas Hahnfeld authored Sep 05, 2022 and Andrei Gheata committed Sep 05, 2022

Commit 5c505fb4 "Ensure[s] that transformation data in nav table is
stored aligned". This breaks the size assert with double precision for
any interesting geometry setup.

The section's attribute is called "zPosition". Before the code would
not find the "z" attribute and give all extruded solids a height of 0.

Create a corresponding UnplacedEllispoid.

Create a corresponding UnplacedEllipticalCone.

Create a corresponding UnplacedEllipticalTube.

and removed the commented dead code.

Removed a temporary test file.

               in DistanceToOut function
               2) Now SafetyToOut uses Wedge to calculate the SafetyToOut for a point
               from the phi section.

               These modifications fixes the mismatches reported by ShapeTester.
               As we are now checking the existence of point in Phi section in DistanceToOut
               Hence, there is a minor performance loss of DistanceToOut.

               Performance figures can be seen in VECGEOM-542 in JIRA

                where previously we were unnecessarily doing some
                calculations, even when the point is outside the Z
                range of polycone, which were not required.

                Clang-formatting also applied after doing the modifications.

Benjamin Morgan authored Jul 21, 2022 and Andrei Gheata committed Aug 19, 2022

ATLAS reported an issue with stuck tracks in their simulation, with
Geant4 Cons,Polycons replaced by VecGeom versions. VecGeom versions
up to 1.1.20 were checked. Triaged to VecGeom's Polycone/Cone
DistanceToOut and Inside functions using kHalfConeTolerance and
kConeTolerance respectively. Can results in points close to surface
being marked as "on surface" by Inside, but "outside" by DistanceToOut.
The overall effect of this is that DistanceToOut always returns an
infinite distance for such points.

VecGeom MR !874 (after 1.1.20) updated the Polycone/Cone implementation to only
use kConeTolerance, and this resolves the problem.

Add ATLAS test case that exposed the problem as a new unit test to
identify any regressions future changes in Polycone/Cone might introduce.

The Visualizer and ShapeDebugger code are only used in tests, but get
compiled into the vecgeom library with the headers not installed.

Move their headers/implementations to a subdirectory of test/. Build
them into a dedicated library, linking this to tests when it is present.

VecGeom/benchmarking and source/benchmarking code is only compiled
into libvecgeom when benchmarking testing is enabled. This makes it
strictly a test-only interface.

Move code into dedicated VecGeomBenchmarking library, built and linked
to tests when appropriate.