Software for Liquid Argon time projection chambers
list of LArSoft releases
Download instructions for larsoft v08_09_00
Download instructions for just larsoftobj v08_06_00
larpandoracontent feature/sgreen_T0Calculation
space charge interface improvements
larevt branch feature/herogers_voxelizedSCE
larreco feature/herogers_dxSCE_calibrationCorrection
ubevt feature/herogers_voxelizedSCE
ubana feature/herogers_dESCE_calibrationCorrection
dunetpc feature/herogers_voxelizedSCE
sbndcode feature/herogers_voxelizedSCE
icaruscode feature/herogers_voxelizedSCE
breaking change
https://indico.fnal.gov/event/19644/contribution/1/material/slides/0.pdf
larcorealg larcore feature/gp_factorizeGeometryBuilding
I have done some refactorisation work for the initialisation of LArSoft
geometry.
Right now, the geometry is described in LArSoft by some “component” objects,
e.g. geo::WireGeo
, geo::TPCGeo
etc., which report things like the wire
position, the wire nearest to a point and so forth. These objects also have
code to interpret the geometry structure (let’s say the GDML description,
although it’s technically not precise), e.g. to discover which wire planes are
inside each TPC.
My modifications extract the interpretation of the geometry source from them,
leaving them with the only task of providing information about the geometry.
The task of constructing them is delegated now to an algorithm
(geo::GeometryBuilder
), after the principle of separation of tasks.
I provide a “standard” implementation of such algorithm, which behaves like
the old code. The algorithm can be replaced or customised without touching the
aforementioned geometry component objects.
On LArSoft/art side, I have updated geo::Geometry
and
geo::AuxDetGeometryService
to always use the standard geometry building
algorithm. They are ready for toolisation, which would be a future step when
we’ll need a custom algorithm.
One noticeable effect of the new structure, which is why I undertook this
effort, is to allow loading a geometry without wires (we’ll attempt something
with pixelated readout planes). I expect geo::PlaneGeo
not to be ready for
that yet, and that will be a following step too.
I have worked under the intention of changes being non-breaking (as long as everything downstream is recompiled).
Usual quality frills: provided unit test of some of the library components,
doxygen documentation included, ran unit tests locally (c2:prof, e17:prof),
triggered integration tests (but it’s still hard to me to interpret the
failures: I believe most experiments had not updated to v08_07_00
yet),
verified that I can still load ICARUS geometry in a python interactive
session.