GitLab issue: #618

Currently concepts are defined in namespace Acts::concept. This collides with the new C++20 concept keyword and is inconsistent with our naming guidelines. Both Doxygen and Sphinx already know the concept keyword and complain loudly about this (see #601 / !614) and I expect that other tools will do so in the future. This should be fixed now to be safe.

A possible resolution would be to move all concepts to

namespace Acts {
namespace Concepts {
   ...
}
}

and concepts implementation details that are not part of the public interface to namespace Acts::Concepts::detail; similar to what is currently being done for regular code and its implementations.

GitLab issue: #724

The BoundParameterTraits::type declares BoundParametersIndices::eQOP as unbound parameter. Since the index refers to a combination of q/p and 1/p depending on q, it consequently declares 1/p as unbound and therefore allows negative momenta.

GitLab issue: #669

Material density is currently defined by the mass density, i.e. mass/volume. Due to our choice of native mass unit this can be a large number that leads to numerical instabilities. The mass density is also not used directly, but only to compute the electron density.

We should therefore replace the mass density with the molar density, i.e. number of atoms measured in mol per volume, as the relevant material parameter. Most related quantities can then be computed as simple products

mass_density = atomic_mass * molar_density * avogadro_constant
molar_electron_density = nuclear_charge * molar_density

To avoid confusion between this parametrizations, the current Material constructors need to be replaced by named constructors, e.g.

Material::fromMassDensity(...);
Material::fromMolarDensity(...);

GitLab issue: #715

and should not be visible directly in the ActsFatras namespace. It should be moved to the ActsFatras::detail namespace.

GitLab issue: #725
Referenced by the following MRs on GitLab: !805

The clone() infrastructure for geometry is unused, should be removed.

GitLab issue: #720
Referenced by the following MRs on GitLab: !786

The material interaction are currently only added to material track for surfaces Interaction. A way to collect material is need to perform validation of the mapping and propagation through volumes.

GitLab issue: #700

The classes to write .obj files representing surfaces, vertices and trajectories is independent of any framework technology.

It should go into Plugins/Obj to be used directly.

The framework versions should then use the writer module.

GitLab issue: #631

The current StepperConcept.hpp is only fulfilled for e.g. the EigenStepper as it checks the existence for certain member variable in the EigenStepper::State which can be modified in the ActionList elements. Since the MultiComponentStepper has a different storage type for its components in the state the concept is not fulfilled anymore. In order to generalize the concept idea to work on both classes of stepping a couple of changes require to be done:

• Identify which assertion tests would differ in both scenarios

• Split the concept into 3 different concepts:

   1.  StepperConcept: A list of assertions which should be fulfilled by all steppers
   2.  SingleComponentStepperConcept: Assertions which are only fulfilled by a single component stepper
   3.  MultiComponentStepperConcept: Assertions which are only fulfilled by a multi component stepper
  

At that point one requires that given a certain stepper a specific ActionList or AbortList fulfills a either the 1. and 2. or the 1. and 3. concept (depending on the stepper). Note: These are the only parts of the whole propagation that explicitly access these members in order to modify them outside of the stepper itself. So this requires to test each element of these lists.

• Depending on the used stepper the ActionList and the AbortList should test each element on the correct application. This check should remain static and be performed by the ActionList and the AbortList without any possible work-around.
• Merge single and multi component actors and aborters into combined actors and aborters. The steering of the right access can then be provided e.g. by std::enable_if checks with underlying std::true_type and std::false_type which is provided in dependence of the steppers and known at compile time.

This implementation would lead to a consistent implementation and allows to switch the stepper without changing these lists (assuming these are declared as "valid" for certain stepper types).

Note: This is only the road map for the stepper. Actually at the current code we find multiple locations (e.g. B-field) where template parameters are used and certain member variables and functions are used without checking the actual existence of them. So there exists a followup checkbox:

• Implement concepts for other template parameters like for the stepper

GitLab issue: #574

ACTS should have more and better benchmarks. Obviously, we're not talking about studying every single line of code in a unit test-like fashion, but we should aim to have easy-to-use microbenchmarks of every component that's known or expected to be performance-critical for at least some ACTS users (e.g. Geometry, EDM, Propagator/Stepper, Kalman Fitter, BField map, Seeding...).

This way, it becomes easy to assess the performance impact of large changes of ACTS and go on a profiling hunt for areas of improvement. In fact, we could even envision to detect regressions automatically if someone can lend us a bit of dedicated hardware for that.

As the toolkit matures, we should also keep the acts-framework examples up to date and improve them, so that it's possible to run a set of semi-realistic tracking scenarios that invoke all major ACTS components, and check how computation time is spread across ACTS components. This allows checking the assumptions that we need to make at this development stage re. what's perf-critical and what isn't.

This issue is half open-ended. Some things we can do today (identify perf-critical components in the current ACTS codebase and write microbenches for them), some things we must continuously keep in mind as ACTS development marches on.

GitLab issue: #615

Position and momentum jacobians in LinearizedTrack model currently do not account for correlations, combine them to a single 8x8 jacobian as used in the propagator instead.

GitLab issue: #593

We could potentially use it to replace our BinUtility and Grid and related classes.

GitLab issue: #592

This needs to wait until LCG has updated to boost 1.70 (foreseen for LCG96), and ATLAS has updated to that LCG version.

See https://sft.its.cern.ch/jira/browse/SPI-1293 for infos

GitLab issue: #670

Averaging material properties over multiple layers e.g. when constructing MaterialProperties is currently done using a mass-weighted average. For the relative atomic mass and the nuclear charge the weighting should be done by quantity instead.

Example

Assume two blocks of materials with N1,N2 atoms/molecules each with atomic masses A1,A2 and nuclear charges. We have a total of N = N1 + N2 atoms/molecules and should have average atomic masses and nuclear charges of

A = (A1*N1 + A2*N2) / (N1 + N2)
Z = (Z1*N1 + Z2*N2) / (N1 + N2)

Using the total masses

m1 = A1*N1
m2 = A2*N2

as weighting factors yields e.g.

Awrong = (A1*m1 + A2*m2) / (m1 + m2)

and is inconsistent with the initial definition of the averages.

GitLab issue: #686

Our current practice of splitting components over multiple repositories, e.g. Core, Fatras, Framework, has lead to undiscovered breakage and impedance missmatch during development. E.g. changes in the Core lead to performance regressions that were discovered only much later in the framework. Git submodule handling is also hard to understand, especially for beginners, and breaks easily.

Switching to a monorepo with optional build components should allow consistent development and testing without the current delay between Core and Framework. Optional component handling is already available in the Core and can be easily reused for this.

At the end, the directory structure of the merged repository should look as follows:

# as-before
Core/
  include/
    ...
  src/
    ...
# as-before (could also be renamed to CorePlugins to clarify the relation to Core)
Plugins/
  DD4hep/
    ...
  # previously handle as special, but can be treated as just another plugin
  Legacy/
    ...
  ...
# cleaned-up content from acts-fatras/Core
Fatras/
  include/
    ...
  src/
    ...
# cleaned-up content from acts-framework
Standalone/
  Algorithms/
    ...
  Detectors/
    ...
  Framework/
    ...
  Io/
    ...
  # formerly 'Examples'
  Run/
    ...
Tests/
  Benchmarks/
    ...
  Examples/
    ...
  # integration tests, can use multiple components
  IntegrationTests/
    ...
  # unit-tests, should always use only a single component
  UnitTests/
    Core/
      ...
    Plugins/
      ...
    Fatras/
      ...
    Framework/
      ...
# as-before
docs/
  ...
# 3rd party libraries that are usually not available via the system
# package manager; shipped as copies and built as part of the regular
# process. use copies instead of submodules to avoid the headache.
# keep this limited to small libraries/ few files by policy.
thirdparty/
  dfelibs/
    ...
  nlohmann_json/
    ...

Target names can use the current style to provide a bit of namespacing, i.e.

# core
ActsCore
# core plugins
# TODO this should be named ActsPlugin... for consistency
Acts...Plugin
# fatras
ActsFatras
# Standalone framework components
ActsStandalone...
# Standalone chains (formerly part of acts-framework)
ActsExample...
ActsGen...
ActsSim...
ActsRec...
# tests
ActsBenchmark...
ActsIntegrationTest...
ActsUnitTest...

This is a major change and will and should not happen at once, i.e. within one of the current weekly/biweekly release cycle. There is also some clean-up in progress for both Fatras and the Framework. This should finish before moving the code back to the main repository.

Propose schedule/ order:

• Prepare main repository
  • Verify CMake tools are sufficient (Existing tools ActsComponentsHelpers.cmake can be used directly for additional components)
  • Make Legacy a regular plugin (#688, !750)
  • Split integration and unit tests (#689, !749)
  • Move nlohman json library to thirdparty (!733)
  • Rename plugin targets to ActsPlugin... (not for now)
• Add Gitlab labels to tag issues for specific components (Available as group labels Component - ...)
• Finish Fatras clean-up Clean up Fatras after import into Core repo
  • acts-fatras#1 now tracked as #693
  • acts-fatras#2
  • acts-fatras#3 now tracked as #694
  • acts-fatras#4 now tracked as #695
  • acts-fatras#5 now tracked as #696
  • acts-fatras#6 now tracked as #697
  • acts-fatras#7 now tracked as #698
• Move Fatras component to main repo (!751)
• Finish Framework clean-up Clean up after import
  • acts-framework#162
  • acts-framework#163
  • acts-framework#164
  • acts-framework#165
  • acts-framework#167
  • acts-framework#174
  • acts-framework#175
  • acts-framework#182
• Move Framework components to main repo

GitLab issue: #690

Intel TBB library is used to parallelise the main loop in ACTS FW FittingAlgorithm.cpp.

Observations:

1. The number of TBB threads can only be configured once (when the TBB scheduler is first initialised). Later or local configurations are ignored (unlike OpenMP or UNIX Pthreads).
2. Since the Sequencer already uses as many threads as physical cores, looks like the processor is already busy full-time, so a later parallelisation seems to be useless.
3. The parallel threads in Sequencer do not need any synchronisation due to data independence. The threads in Fitter need to synchronise on the output result: the trajectories. Therefore having the parallelisation done only here would not be so beneficial as having it in Sequencer.

See attached PDF with time measurements which seems to support the above observations: TBBFittingParallelExecutionTimes.pdf

Code is committed in ACTSFW/parallel-fitter branch.

GitLab issue: #684

Currently the setup script bakes the install path. It came up in atlas/atlasexternals!589, maybe we should change to have this relative, and thus make the install directory relocatable.

/cc @ msmk

GitLab issue: #651

Separating the original input track from the TrackAtVertex object (and hence removing the templating) could further simplify the entire vertexing interface by not having to template all fitters to the input track type anymore.

GitLab issue: #699
Referenced by the following MRs on GitLab: !757

In the ITk case and and other detector geometries, the binning on layers can be far from regular. The SurfaceArray should at least be tested for such a setup.

Ideally, this would come with an encapsulation of std::vector<DetectorElement> -> SurfaceArray module which then could be called from the several geometry plugins.

GitLab issue: #721
Referenced by the following MRs on GitLab: !788

To be able to extend the mapping to volumes it is necessary to be able to map volumes material.

GitLab issue: #620

• Define a common, simplified, detector setup that can be used as a test fixture for all tests.
• Define a common measurement generation fixture that can be shared among tests.

Suggested geometries:

• 4-layer barrel-like, silicon detector
• forward, telescope-like silicon detector

GitLab issue: #703

Energy loss is simulated by drawing from a Landau distribution. The Landau distribution is parametrized by a location and a scale which do not correspond directly to the most-probable energy loss value and the energy loss sigma. Yet, those parameters are currently used as distribution parameter.

We need to find the correct relation and use the right parameters.

GitLab issue: #717

Arguments

Non-exhaustive list of pro/contra arguments.

For staying with CERN Gitlab

• Gitlab is fully integrated and handles the repos, issues, and the CI
• Hosted at CERN with dedicated support and infrastructure; does not rely on free-tier of external services.

Against staying with CERN Gitlab

• Easier participation of non-CERN users.
• External services can provide more functionality then what is available with Gitlab

Requirements for another hosting solution

A non-exhaustive list of functionality that we need to host the Acts development in addition to hosting just the git repository.

• Issue tracker
• CI builds with runners that can access CVMFS (to test with LCG releases)
• Sufficient resources to run our extensive builds and unit tests
• Possibility to run multi-threaded tests
• ...

GitLab issue: #541

Original author Andreas Salzburger @ asalzbur

GitLab issue: #581

go through code where config is used and change to appropriate units.

The following discussion from !556 should be addressed:

• @ asalzbur started a discussion:

  Can you please add units to this code ?

GitLab issue: #679

The following discussion from !718 should be addressed:

• @ jinz started a discussion: (+1 comment)

  So it seems every stepper should have the updateStepSize concept

There's still some open discussions on the Stepper concept, I think we should integrate this here. Adding @ fklimpel as watcher.

GitLab issue: #638

This issue will replace the old one.
The MultiTrackParameters will be templated with CurvilinearParameters or BoundParameters, which contains a set of two same type parameters, now CurvilinearParmeters type is not in use.

GitLab issue: #540

Original author Andreas Salzburger @ asalzbur

Streamline the naming of covTransport and covarianceTransport() for the EigenStepper and AtlasStepper.

GitLab issue: #714

Track parameters have different constructor interfaces depending on the charge policy. Having a consistent constructor interface would allow more generic usage of track parameters.

GitLab issue: #527

Original author Paul Gessinger-Befurt @ pagessin

See title. The pre-implemented Aborters and Actors should not be in detail

GitLab issue: #634

Currently the track linearization used in vertexing is based on a helical track model.
A track model independent track linearization using information provided only by the propagator could be developed.

GitLab issue: #673

• Use #pragma instead of manual include guards.
• Add common copyright notice.
• Remove #define ACTS_VERSION. Has been replaced by the constexpr variables.
• Use const char* as type for the commit hash. This is how the string is actually stored and avoids having to include string_view header.

GitLab issue: #653

As discussed on Mattermost, this change

D(3, 7) =
      h * state.options.mass * state.options.mass *
      stepper.charge(state.stepping) /
      (stepper.momentum(state.stepping) *
        std::hypot(1., state.options.mass / stepper.momentum(state.stepping)));

from !661 seems to obliterate propagation performance, at least the runtime of the fitting example increases by about a factor of 5.

It seems like this is an effect of the assignment of a non-zero value to D(3, 7) rather than the calculation happening here.

@ fklimpel can you follow up on this?

GitLab issue: #712

Layer objects got more and more the functionality of Volumes.

Actually it only needs:

• DetectorVolumes with boundary portals

InternalDescriptors:

• ContainerDescriptor for navigation in the volume hierarchy
• LayerDescriptor for volumes representing a layer
• BoundingHieararchyDescriptor for volume representing a BB hiearachy

This will be tested on a new DetectorVolume which will replace eventually the TrackingVolume, this should help for ITk, ATLAS TRT, ATLAS Calorimeter, etc.

GitLab issue: #711
Referenced by the following MRs on GitLab: !779

For the description of e.g. Belle-2 we need conical volume bounds.

GitLab issue: #668

Currently, the MaterialInteractor does not differentiate between different types of energy loss. This should be configurable.

GitLab issue: #660

The bounded track parameters in Acts/EventData/SingleTrackParameters.hpp store 6-vector of local track parameters and derived position and momentum vectors. The later are pure duplicated data and effectively double the size. This duplicate information should be removed. In cases where really the free parameter information is needed, the new free parameters should be used instead.

This originated from the follwoing discussion

GitLab issue: #671

Material defines the material properties for a material of undefined dimensions while MaterialProperties defines a block/slab/slice of a concrete material.

Suggestion: rename MaterialProperties to MaterialSlab.

GitLab issue: #680
Referenced by the following MRs on GitLab: !721

The following discussion from !685 should be addressed:

• @ asalzbur started a discussion:

  The DD4hepVolumeBuilder is missing in this, which creates a linking error.

GitLab issue: #683

There is a simple algorithm based on Hans Drevermann's z vertex finder which already has been transcribed into acts-core. The code is already written and needs only to be cleaned up.

It takes combinations of spacepoints and extrapolates them to the beam line in order to histogram vertices, see attached sample plot for a test event:

GitLab issue: #687

The PropagationIntegrationTest does a lot of work. Its execution time is somewhat reasonable in "release" -O2 builds, at around a minute here, but that degrades into a painful extreme of 2 hours and a half when run on "debug" -O0 builds, which if the usual 30x orders of magnitude apply means that it would typically take several days to run such a build under a valgrind tool (memcheck, verrou...).

I personally find this a bit concerning, because some bugs are hard to track down on a release builds, even with debugging symbols on. But maybe I'm overreacting an others don't think that this is a problem?

If we do agree that this is a problem, how do we want to approach it? Here are some tentative ideas:

• Break the test down into multiple sub-programs.
• Evaluate wisdom of tuning down iteration count in long-running parts.
• If that loses coverage/physics, then consider allowing the caller of the test to execute or replay only a subset of it (e.g. "re-run iterations 10000 to 10100").

GitLab issue: #662

This is a rolling issue to monitor clang-tidy reports

+-----------------------------------------------------+---------+
| code                                                |   count |
|-----------------------------------------------------+---------|
| cppcoreguidelines-pro-bounds-pointer-arithmetic     |     155 |
| cppcoreguidelines-special-member-functions          |     104 |
| cppcoreguidelines-pro-bounds-constant-array-index   |      69 |
| modernize-pass-by-value                             |      60 |
| cppcoreguidelines-pro-type-member-init              |      40 |
| misc-macro-parentheses                              |      37 |
| readability-else-after-return                       |      29 |
| cppcoreguidelines-pro-type-const-cast               |      24 |
| misc-noexcept-move-constructor                      |      22 |
| readability-braces-around-statements                |      14 |
| modernize-use-emplace                               |      14 |
| misc-move-const-arg                                 |      14 |
| performance-unnecessary-copy-initialization         |       8 |
| modernize-use-equals-delete                         |       8 |
| readability-misleading-indentation                  |       7 |
| cppcoreguidelines-pro-bounds-array-to-pointer-decay |       6 |
| readability-redundant-control-flow                  |       6 |
| readability-simplify-boolean-expr                   |       5 |
| misc-redundant-expression                           |       4 |
| misc-unused-using-decls                             |       4 |
| readability-avoid-const-params-in-decls             |       4 |
| modernize-loop-convert                              |       2 |
| misc-use-after-move                                 |       2 |
| clang-analyzer-deadcode.DeadStores                  |       1 |
| misc-definitions-in-headers                         |       1 |
| readability-redundant-string-init                   |       1 |
| modernize-raw-string-literal                        |       1 |
| readability-redundant-smartptr-get                  |       1 |
| modernize-make-unique                               |       1 |
| clang-analyzer-core.UndefinedBinaryOperatorResult   |       1 |
| misc-suspicious-semicolon                           |       1 |
| readability-redundant-declaration                   |       1 |
| performance-inefficient-vector-operation            |       1 |
| modernize-use-noexcept                              |       1 |
| modernize-deprecated-headers                        |       1 |
| misc-sizeof-expression                              |       1 |
| modernize-make-shared                               |       1 |
+-----------------------------------------------------+---------+

The Alternative name of this issue is:
"Sometimes I sit in interesting meetings and I decide to not fully pay attention, so at least I can do some clang tidying."

GitLab issue: #601
Referenced by the following MRs on GitLab: !614

Restructure the documentation to allow both high-level documentation with references to the low-level doxygen documentation.

GitLab issue: #520

Original author Andreas Salzburger @ asalzbur

For convenience, create a simplified StrawSturface constructor just from the wire direction.

GitLab issue: #665

The fact that Steppers are allowed to overstep in the propagation requires the setting of a tolerance. Correctly, the overstepping tolerance should be determined by the magnetic field (and step length/accuracy length), this can optimise the navigation.

The following discussion from !699 should be addressed:

• @ fklimpel started a discussion: (+3 comments)

  If you want to have it private you need a setter or something similar

GitLab issue: #710

Even though the ObjHelper and PlyHelper are not depending on anything, the visualisation should be in a separated Visualization folder in order to have a dedicated separation for UnitTests/Visualization.

The Visualization can then have more dedicated helpers for TrackingVolume, TrackingGeometry, Surfaces and even EventDataModel.

This will come in three steps:

• split visualisation off from Utilitites
• make Surface::draw() consistent and add unit tests
• make VolumeBounds::draw() consistent and add unit tests

GitLab issue: #542

Original author Andreas Salzburger @ asalzbur

GitLab issue: #509

Original author Andreas Salzburger @ asalzbur

GitLab issue: #704

Currently, the referenceSurface is passed to KalmanFitterOptions as a non-owning regular pointer. This could cause potential segfault issue since the surface object could be constructed locally outside of KF (in principle, the target surface could be any surface defined by the user). A safer way to go is to use shared_ptr for the referenceSurface in KalmanFitterOptions and targetSurface in KalmanActor.

GitLab issue: #579

Two issues to be updated in the MagneticField:

(1) Currently, only the

field(const Vector3D& position, Cache& cache) const;

call is MagneticFieldContext aware. The pure field(const Vector3D& position) method is not yet implemented as such.

(2) The derivate vector is not yet filled with zeros for some fields, should be implemented.

GitLab issue: #674

We currently do not test that installed CMake configs work. We should have a small example project that builds a (non-trivial) example executable using Acts via the find_package(...) mechanism. This should look as simple as a single directory in the repository:

ExampleProject\
ExampleProject\CMakeLists.txt
ExampleProject\Propagate.cpp

Having this directly in the repository would allow us to build this in the CI using the installed build products from one of the Core build jobs. In principle, this could also be done as a separate project. Gitlab supports multi-project pipelines but only in the premium edition. This is currently not an option for us.