GitLab

Jenkins builds use an LCG view for build dependencies, which includes
an install of VecCore. With the default being to use a system install
on VecCore, the removal of the fallback to builtin does not change
the behaviour here.

Add BUILTIN_VECCORE=OFF to default build arguments to make this use
case explicit.

GitLab CI setup assumed fallback to builtin VecCore as builds do
not have an external install in their setups. This caused failures
in CI following removal of fallback.

Set BUILTIN_VECCORE to ON explicitly in build jobs on GitLab.

Reported in VecGeom-583. We should not fallback to the builtin VecGeom
option if use of external was requested but could not be found.

Remove fallback to builtin VecGeom when external package requested and
not found.

Support switch between builtin/external in current build directory to
ensure consistent builds.

TODO: Use of FetchContent in CMake >= 3.11 is preferred, but VecCore
does not support this well yet as it is not designed to be used as
a subproject.

CMake has supplied cmake_parse_arguments natively since version 3.5.
VecGeom's local implementation is both obsolete and can cause errors
in the current cmake as it overrides the builtin.

Remove the local implementation, relying on CMake's native support.

John Apostolakis authored Nov 05, 2021 and Gabriele Cosmo committed Nov 05, 2021

[VECGEOM-564] Adapt FillUncontainedPoints for "full" volumes, add 2nd CheckDaughterIntersections in NewSimpleNavigator

Guilherme Amadio authored Oct 26, 2021 and Benjamin Morgan committed Nov 05, 2021

The ProcessorCount module returns the number of logical cores,
which may use too many resources and lock up the machine. This
sets the parallelism for building and testing using CMake's builtin
variables and uses only the total number of physical cores to avoid
using too many resources at once.

UMESIMD is no longer maintained and is known to have issues in testing
with VecCore. VecCore and eventually native compiler, support for
std::simd will render it obsolete.

Remove UMESIMD from VecGeom's BACKEND option. Remove other
use/references in C++ and configuration/CI code.

- Treat fast-math options correctly
- Use -march=native rather than -xHost
- Use -mavx2 instead of -xCORE-AVX2 (breaks on AMD machines)
- Add support for new Intel compiler based on LLVM

The new compiler still has to be configured as icc/icpc,
as icx/icpx are not yet supported by VecGeom's build system.

Avoid using Vector3D in data structures copied host<->device, leading to wrong content in vector mode due to inheritance (and memory layout) of cxx:Vector3D vs. cuda::Vector3D.

The pre-checks for valid torus intersection were protected by a EarlyReturnAllowed, thus ignored in CUDA and leading to false positive crossings.

- Improved accounting of tolerances
- Invalidate normals for corners (noSurface > 2), while faces & edges (noSurface=1,2) are okay
  - fixes DistanceToOut() for tracks scratching a polycone surface
  - fixes stuck tracks observed in Celeritas rasterizer

Used a const instead of constexpr because Real_v is not a POD in the vector backend.

The changes simplify significantly the code around calls to those functions,
as local squares don't need to be called just to provide as arguments.

Identified in upstream use by Geant4 - required compiler flags for
using VecGeom (ISA and alignment) are not exported as CMake usage
requirements for the imported targets. The client is required to use
the CMake variables set in VecGeomConfig.cmake, and this may not be
obvious or always done.

Add the required flags to the VecGeom target as CMake compile options
so they are propagated to clients linking the imported target.

NB: These flags currently must be added to VecGeom's build-time
CMAKE_CXX_FLAGS as well to support CUDA builds. This leads to repitition
of the flags on the compile command line, but there should be no
side effects as the flags used do not change behaviour when repeated.