pandorapfa / larpandora

Pandora App to drive reconstruction in the LArSoft / Art framework

PandoraPFA

Metadata package to bring together and build multiple Pandora libraries

PandoraPFA is distributed under the GPLv3 License

License and Copyright

Copyright (C), PandoraPFA Authors

PandoraPFA is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

larpandora's Issues

Bug in fcl param names in the Bayes dE/dx tool in Pandora Modular Shower Creation

In the Bayes dE/dx tool in the Pandora Modular Shower Creation, there is a slight bug in the fcl parameter names.

I was using version v09_01_00 of larpandora for v09_03_00 of larsoft.

The parameters used to be called ProbDiff and ProbDiffSeed, but in the Modular Shower's showertools.fcl these have been renamed as ProbSeedCut and ProbPointCut. (Forget which maps to which offhand).

However, in the Module itself, these names were not changed:

fProbSeedCut(pset.get("ProbDiff")),
fProbPointCut(pset.get("ProbDiffSeed")),

which leads to the module complaining. This is of course easily worked around in one's job fcl, but in any case probably the committed versions should be fixed!

Gaps creation assumes a wire direction for the Y/W views.

The gaps creation logic for U and V views uses the appropriate transformation plugin to convert coordinates e.g.:

larpandora/larpandora/LArPandoraInterface/LArPandoraInput.cxx

Line 337 in a7bb47e

const float firstU(pPandora->GetPlugins()->GetLArTransformationPlugin()->YZtoU(firstXYZ[1], firstXYZ[2]));

larpandora/larpandora/LArPandoraInterface/LArPandoraInput.cxx

Line 346 in a7bb47e

const float firstV(pPandora->GetPlugins()->GetLArTransformationPlugin()->YZtoV(firstXYZ[1], firstXYZ[2]));

The W/Y code assumes a wire direction, I figure because of the inherent Y assumption, and does not use any transformation to convert coordinates:

larpandora/larpandora/LArPandoraInterface/LArPandoraInput.cxx

Line 328 in a7bb47e

const float firstW(firstXYZ[2]);

This will be problematic for ICARUS once it comes online, assuming it has some amount of dead channels.

Issue in PandoraGeometry when geometries include offsets

It seems to be the case that Pandora's geometry doesn't properly handle offsets of the TPC active volume relative to the overall TPC volume (even specified in the GDML).

LoadGeometry translates (0,0,0) of the TPC to the world coordinates (LocalToWorld) then subtracts/adds half the active volume width, i.e. it seems to have the assumption that the translation of (0,0,0) should correspond to the center of the drift volume. However, this can lead to issues when the center of the TPC volume does not align with the center of the active volume.

For example, this was noticed by seeing that ICARUS event displays had slices/tracks stopping a bit before the expected cathode position even while the hits themselves seem to continue. In this example, comparing a TPC's translation of (0,0,0) and the center using ActiveBoundingBox (e.g. 0.5*(AVolBoundBox.MaxX()+AVolBoundBox.MinX())), they differed by the amount of the shift given via a "posActiveInTPC0" line in the gdml.

(Shout-out to Dom Brailsford, as always, for his helpfulness)

An idea "fix" is seen here (brucehoward-physics@a998040) but I'm not sure if this is the best or even preferred way.