Restructure BDSIM into more libraries

[Laurie Nevay]

Currently we have a mixed bag of layout of files. Problems:

• Executables are mixed with libraries and are manually removed from glob lists of sources in the CMake (not so good).
• The ‘analysis’ library has headers mixed with sources.
• The parser uses .h instead of .hh (inconsistent with rest of code).
• The parser is a singleton and we have circular linkages which makes the linking order actually matter (generally bad).
• We can’t use analysis code in main BDSIM due to the library layout (circular linkages)
• There is duplication of data writing and loading in effect - really should be done by one class in one library
• The bdsim/src and bdsim/include directories have grown considerably and are too big now (although our naming convention does help)
• We should ensure that users can make use of BDSIM as a C++ class library (given new CMake and interfaces)

The major motivation is that we can’t currently use the histogram merging to create correct per-event run average histograms, because this would require linking agains the rebdsim library which links back against bdsim. We also can’t have the --optics option (Issue #213) because this would also require use of the rebdsim library.

From my reading, whilst there’s no hard rules about how to lay out a C++ package, current convention is that executables are often separated from libraries. This would simplify our CMake somewhat.

We can also make a single CMake function to define a library that takes a directory and a name so we’ll reduce the amount of CMake overall improving maintainability.

Only very few special files will need a CMake configuration step and can probably be kept separate.

This will have to be done roughly when a good number of branches are closed as it will make it quite difficult to merge into other branches.

Concrete benefits:

• Run histograms will be already per-event averages. rebdsimHistoMerge will be simplified or unnecessary.
• We can do integrated analysis at the end of BDSIM (i.e. run rebdsim on data). Including calculate optical functions.
• Conceptually, we could inspect their supplied analysisConfig with BDSIM and turn on the relevant options of what to generate (per event transient) and store to file to match their histograms exactly. Or have a minimal data output option.
• More maintainable and simplified CMake

‌

‌

[Laurie Nevay]

We should also consider using the cmake flag BUILD_SHARED_LIBS and not specify STATIC or SHARED in add_library commands throughout. That way the executables will be all linked to the shared or static library as appropriate (due to us only using one library name at a time). Currently, while we’ve introduced options to build the static libraries we don’t link against them.

https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html#variable:BUILD_SHARED_LIBS

[Laurie Nevay]

possible libraries

analysis (analysis classes, histogramming)
aperture
beam (bunch generation)
comparator
convert
core (bdsim class, g4 actions, globals)
data (output writing, output classes, non-g4 output classes, data loading)
field (arrays, interpolation, field factory, field classes)
geometry (beam pipe, magnets, cavities, beam line elements, beam lines, component factory, extents, materials, samplers)
interpolator
modules/AWAKE
modules/nistmaterials
parser
physics (our processes, physics lists)
sensitivity (hits, SD classes, primitive scorers, trajectory points)
tracking (our integrators)
utilities
visualisation (vis manager)

executables

bdsinterpolator
bdsim
bdsimCombine
bdskim
comparator
edbdsim
gmad
makematerialfile
rebdsim
rebdsimCombine
rebdsimHistoMerge
rebdsimOptics
rebdsimOrbit