Warning
This website is outdated!. ACTS documentation has moved to ReadTheDocs at:
acts.readthedocs.io
Integration
Technical integration
In order to use Acts in your project, you need to integrate it in your build. Currently, only CMake-based builds are supported.
Customizing Acts
Acts can be customized in several ways in order to allow seamless integration in the experiment software.
Screen output logging
A default screen logging system is integrated in Acts, but can be replaced with the experiment's logging system.
Plugins at compile time
Several implementation details of Acts can be reconfigured at compile time. These are header-only files that exchange the default implementations of Acts.
Change of parameter definition
This can be done by providing the different parameter definition file and declaring it as
ACTS_PARAMETER_DEFINITIONS_PLUGIN='<path_to>/<filename.hpp>'
TODO: Write a CI test for this
Change of Identifier
class
The Identifier class can be exchanged by declaring:
ACTS_CORE_IDENTIFIER_PLUGIN
TODO: Write a CI test for this, together with Identifier change
Interfacing with magnetic field
The magnetic field integration is done using a concept
implementation that is designed for
field cell caching. The propagation modules take the magnetic field as a template argument,
hence providing the correct concept guarantess compatibility with Acts.
System of Units
Acts uses a set of system of units and its interanl code tries to minimise unit conversions, however, when converting into the Acts data model, this should be done using the Acts units
Internally, Acts uses a set of SI2Nat<>
template funtion to free the code from conversion
constants.
/// @brief physical quantities for selecting right conversion function
enum Quantity { MOMENTUM, ENERGY, LENGTH, MASS };
/// @cond
template <Quantity>
double
SI2Nat(const double);
template <Quantity>
double
Nat2SI(const double);
TODO: Write a unit test for this, investigate if we can do this as a PLUGIN
as well
Configuration
Acts does not come with a dedicated configuration system to bind to any experiments software.
Instead, a simple decision has been taken to equip every configurable component of Acts with a
nested Config
struct.
This struct object is used to construct the corresponding Acts tool, e.g.
class CylinderVolumeBuilder : public ITrackingVolumeBuilder
{
public:
/// @struct Config
/// Nested configuration struct for this CylinderVolumeBuilder
struct Config
{
/// the trackign volume helper for construction
std::shared_ptr<const ITrackingVolumeHelper> trackingVolumeHelper = nullptr;
/// the string based indenfication
std::string volumeName = "";
/// The dimensions of the manually created world
std::vector<double> volumeDimension = {};
/// the world material
std::shared_ptr<const Material> volumeMaterial = nullptr;
/// build the volume to the beam line
bool buildToRadiusZero = false;
/// needed to build layers within the volume
std::shared_ptr<const ILayerBuilder> layerBuilder = nullptr;
/// the envelope covering the potential layers rMin, rMax
std::pair<double, double> layerEnvelopeR
= {1. * Acts::units::_mm, 1. * Acts::units::_mm};
/// the envelope covering the potential layers inner/outer
double layerEnvelopeZ = 10. * Acts::units::_mm;
/// the volume signature
int volumeSignature = -1;
};
};
To configure Acts tools, thus, one has to guarantee that necessary configuration parameters are forwarded through the framework configuration mechanism.