Project

General

Profile

Bug #17250

Adding geo::kX view and TimeOffsetX to DetectorProperties for rotated dual phase geometry gives segmentation faul from trajcluster and pmtrack

Added by Christoph Alt about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Geometry
Target version:
-
Start date:
07/21/2017
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

Hi,

When loading the rotated protodune dual phase geometry (dunetpc/dune/Geometry/gdml/protodunedphase_rot.gdml) with drift in y and views in x (geo::View_t = geo::kX = 4) and z (geo::View_t = geo::kZ = 2), I got the following error:

%MSG-s ArtException:  lar 16-May-2017 23:18:17 CEST JobSetup
cet::exception caught in art
---- OtherArt BEGIN
 ServiceCreation
 ---- CalculateXTicksParams BEGIN
   Bad view = 4
 ---- CalculateXTicksParams END
 cet::exception caught during construction of service type detinfo::DetectorPropertiesServiceStandard:
---- OtherArt END
%MSG

The problem is that the geo::kX case (and TimeOffsetX) is not implemented in DetectorProperties.
I added them, see branch feature/chalt_XPlaneForRotatedDPGeometry in lardata.
Files I changed:
detectorproperties.fcl
DetectorPropertiesStandard.h
DetectorPropertiesStandard.cxx
DetectorProperties.h

The rotated geometry is loading with this fix (I can't test much more right now since the drift in y is not implemented yet at the g4 stage), but:

When loading the unrotated dual phase geometry (dunetpc/dune/Geometry/gdml/protodunedphase.gdml, with drift in x and views in y and z) with this fix, I get a segmentation fault from trajcluster and pmtrack (linecluster works). To reproduce, checkout my branch in lardata and do:

reco with raw hit finding and trajcluster:

lar -c srcs/dunetpc/fcl/protodunedp/gen/prod_protodunedp.fcl -n 1 -o gen.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/g4/standard_g4_protodunedp.fcl gen.root -o g4.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/detsim/standard_detsim_protodunedp.fcl g4.root -o detsim.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/reco/rawhitfinding_reco_protodunedp.fcl detsim.root -o reco.root (segmentation fault from trajcluster)

reco with gauss hit finding and linecluster:

lar -c srcs/dunetpc/fcl/protodunedp/gen/prod_protodunedp.fcl -n 1 -o gen.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/g4/standard_g4_protodunedp.fcl gen.root -o g4.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/detsim/standard_detsim_protodunedp.fcl g4.root -o detsim.root (no problem)
lar -c srcs/dunetpc/fcl/protodunedp/reco/standard_reco_protodunedp.fcl detsim.root -o reco.root (segmentation fault from pmtrack)

Both reconstructions work fine without the fix.

Let me know if you need more information!

Thanks,
Christoph

P.S.: using v06_44_00

History

#1 Updated by Gianluca Petrillo about 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo

Thank you for reporting this, Christoph.

Actually, the work was already done, but was lying on a feature branch that has been forgotten: feature/gp_AddViewXsupport in lardata.
I have picked a couple of changes that I had missed (or that I had opted not to adopt, but that make sense to me now).
I have not picked the changes to the FHiCL file. In fact, I wish I could safely remove the other TimeOffset# settings from that FHiCL file: they are detector-specific and it makes no sense to have them in a generic configuration.

Now testing.

#2 Updated by Gianluca Petrillo about 3 years ago

  • % Done changed from 0 to 100

Testing was successful.
Experiment repositories included ArgoNeuT, DUNE, Icarus, LArIAT, MicroBooNE and SBND.

#3 Updated by Gianluca Petrillo about 3 years ago

  • Description updated (diff)
  • Status changed from Assigned to Resolved
  • Occurs In v06_44_00 added

#4 Updated by Gianluca Petrillo about 3 years ago

  • Description updated (diff)

#5 Updated by Christoph Alt about 3 years ago

Hi Gianluca,

Thank you! Are you planning on merging this feature branch into develop?

#6 Updated by Gianluca Petrillo about 3 years ago

It is scheduled for merge in the coming release: I will not merge it directly to develop branch, but the merge should happen by tomorrow.

#7 Updated by Gianluca Petrillo about 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF