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.