Project

General

Profile

Bug #16007

Wrong charge projection in dual-phase geometry

Added by Robert Sulej over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Simulation
Target version:
-
Start date:
03/28/2017
Due date:
% Done:

100%

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

Description

Simulation in plane 0 in DP gives significantly wrong results at some track orientations.

Andrea will provide fcl's, errors and a picture of simulation result.

evd_raw2.png (80.2 KB) evd_raw2.png event display for raw data Andrea Scarpelli, 03/28/2017 02:16 PM
evd_raw.png (85.9 KB) evd_raw.png event display for raw data Andrea Scarpelli, 03/28/2017 02:16 PM
ortho3D.png (28.9 KB) ortho3D.png ortho3d display (true trajectory) Andrea Scarpelli, 03/28/2017 02:16 PM
evd_raw3.png (67.2 KB) evd_raw3.png event display for raw data (unzoom) Andrea Scarpelli, 03/28/2017 02:16 PM
prod_protodunedp.fcl (933 Bytes) prod_protodunedp.fcl prod_single muon 45deg in YZ Andrea Scarpelli, 03/28/2017 02:16 PM
Screen Shot 2017-03-28 at 11.10.12 PM.png (25.8 KB) Screen Shot 2017-03-28 at 11.10.12 PM.png ortho dunefd dp Andrea Scarpelli, 03/28/2017 04:11 PM
Screen Shot 2017-03-28 at 11.10.33 PM.png (62.9 KB) Screen Shot 2017-03-28 at 11.10.33 PM.png raw dunefd dp Andrea Scarpelli, 03/28/2017 04:11 PM
Screen Shot 2017-03-31 at 11.36.22 AM.png (53.7 KB) Screen Shot 2017-03-31 at 11.36.22 AM.png Andrea Scarpelli, 03/31/2017 04:37 AM

Related issues

Blocked by dunetpc - Bug #16015: Dual phase detector geometry dunetpc/gdml/protodunedphase.gdml not correctly loadedClosed03/28/2017

History

#1 Updated by Lynn Garren over 3 years ago

Robert, how serious is this bug? Will the promised information be submitted soon?

#2 Updated by Dorota Stefan over 3 years ago

Hello, I think I get error in the reco stage related to this issue:

%MSG-w DisambigAlg35t:  HitFinder35t:hitfd 28-Mar-2017 12:38:22 CDT  run: 1 subRun: 0 event: 3
Could not find disambiguated hit for  C:0 T:0 P:1 W:358 7999
%MSG
%MSG-s ArtException:  PostPathEndRun end_path 28-Mar-2017 12:38:50 CDT  PostEndRun
cet::exception caught in art
---- EventProcessorFailure BEGIN
  An exception occurred during current event processing
  ---- ScheduleExecutionFailure BEGIN
    ProcessingStopped.

    ---- Geometry BEGIN
      Can't find nearest wire for position ( 0 ; nan ; nan ) in plane C:0 T:9 P:2 approx wire number # 0 (capped from -2147483648)
      cet::exception going through module
    ---- Geometry END
    Exception going through path reco
  ---- ScheduleExecutionFailure END
  cet::exception caught in EventProcessor and rethrown
---- EventProcessorFailure END
%MSG
%MSG-s ArtException:  PostPathEndRun end_path 28-Mar-2017 12:38:50 CDT  PostEndRun
cet::exception caught in art
---- EventProcessorFailure BEGIN
  An exception occurred during current event processing
  ---- ScheduleExecutionFailure BEGIN
    ProcessingStopped.

    ---- Geometry BEGIN
      Can't find nearest wire for position ( 0 ; nan ; nan ) in plane C:0 T:9 P:2 approx wire number # 0 (capped from -2147483648)
      cet::exception going through module
    ---- Geometry END
    Exception going through path reco
  ---- ScheduleExecutionFailure END
  cet::exception caught in EventProcessor and rethrown
---- EventProcessorFailure END
%MSG
Art has completed and will exit with status 65.

This has happened for protodune SP geometry. I can check how often does this happen, if it happens often the problem is serious.

#3 Updated by Robert Sulej over 3 years ago

It seems to be serious problem in dual-phase geometries.

Andrea will add information on DP soon.

I'll add Tingjun, as he may know where to look in hit disambiguation code.

#4 Updated by Andrea Scarpelli over 3 years ago

Hi, sorry if I am late.
I am running the usual g4-detsim steps for protodune dp. The example is related to muons @2GeV and with 45deg in the YZ planes (see attached .fcl), but the same issue occurred with pions and protons and also using the dunefd-dp workingspace geometry. For g4 and detsim steps I used the standard .fcl in dunetpc/fcl/protodune.

During the g4 step the following error message is displayed:

%MSG
%MSG-w LArVoxelReadout:  LArG4:largeant 28-Mar-2017 21:05:43 CEST  run: 21000015 subRun: 0 event: 3
unable to drift electrons from point (21.3059,289.467,535.705) with exception ---- Geometry BEGIN
  Can't find nearest wire for position ( 300.127 ; 289.781 ; 535.651 ) in plane C:0 T:3 P:0 approx wire number # 0 (capped from -19)
---- Geometry END

This is appears quite commonly in this step for dp, we inferred it was related to the dead volume between the two CRMs, but now it appears more frequently than before.

From the event display (see the attached screens) it looks like the charge is correctly projected only on one plane and not on the others. A similar scenario would occur for muons traveling parallel to one of the wire planes, but in this case all the wires should share a similar charge since I generated muons at 45deg (see the Ortho3D with the true muon trajectory).

#5 Updated by Gianluca Petrillo over 3 years ago

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

#6 Updated by Gianluca Petrillo over 3 years ago

  • Occurs In v06_28_01 added

#7 Updated by Tingjun Yang over 3 years ago

I can comment on this problem. I believe the error is in LineCluster and it was caused by a recent change to GeometryCore::IntersectionPoint(). Gianluca has fixed this in the develop head of larcore. I believe it is unrelated to the other problem of "can't find nearest wire for position ..."
Dorota Stefan wrote:

Hello, I think I get error in the reco stage related to this issue:

[...]

This has happened for protodune SP geometry. I can check how often does this happen, if it happens often the problem is serious.

#8 Updated by Gianluca Petrillo over 3 years ago

I think there are two distinct problems.
Dorota, would you mind opening a separate ticket for that, so that we can track it separately?
Also, is this problem showing only in DUNE 35t runs?

#9 Updated by Gianluca Petrillo over 3 years ago

As Tingjun said, that is in fact similar to the problem he had reported. It is supposed to be solved in develop.
Have you tried running with develop?

#10 Updated by Gianluca Petrillo over 3 years ago

Andrea: that is a non-fatal error message, right?

If my understanding is correct, it is a situation that was foreseen. The charge is deposited outside the coverage of the wires. Then we ask "which is the closest wire"?
The question here is which answer we want in that case.
In the current implementation, that charge is not read out.

(note that my analysis is not based on anything else that the reported error message, and it might be just wrong)

#11 Updated by Tingjun Yang over 3 years ago

Could someone remind me the orientation of the wires on the two planes? Are they vertical and horizontal?

#12 Updated by Andrea Scarpelli over 3 years ago

Hi,

The error is not fatal.
In dual phase we should have two collection planes perpendicular to each others.

To summarize: the charge is not projected on plane 0. Only very few wires in plane 0 see the track, while in this geometry both planes should see the same. The error message is a sign, I think, that the charge can't be projected on the correct wire.

If this can help, I can upload also some event displays related to a a muon parallel to one of the two planes.

#13 Updated by Tingjun Yang over 3 years ago

One more data point: I just took a look at the DUNE FD simulation and it does not seem to have this problem.

#14 Updated by Andrea Scarpelli over 3 years ago

If you are talking about my error, I have it also for the far detector (workingspace geo). Please check the attached displays.

#15 Updated by Tingjun Yang over 3 years ago

I was referring to the single phase geometry.
Andrea Scarpelli wrote:

If you are talking about my error, I have it also for the far detector (workingspace geo). Please check the attached displays.

#16 Updated by Gianluca Petrillo over 3 years ago

I see a load of error messages like:

%MSG
%MSG-w LArVoxelReadout:  LArG4:largeant 28-Mar-2017 20:44:05 CDT  run: 1 subRun: 0 event: 1
step cannot be found in a TPC
---- TPCOutOfRange BEGIN
  Request for non-existant TPC 10
---- TPCOutOfRange END

Do you see those too, or is it a problem with my configuration?

You can't really run the FHiCL file you attached (geometry: protodunedphase.gdml) and then the "standard" protoDUNE_g4.fcl (geometry: protodune_v3.gdml).
Just to be safe: could you confirm that you are modifying the G4 configuration to use a service configuration (in particular, geometry) consistent with the generation?

#17 Updated by Gianluca Petrillo over 3 years ago

  • % Done changed from 0 to 10

I was trying to understand the detector by reading how LArSoft sees the detector.
It sees it wrong.
Until the issue with the geometry description is not fixed (issue #16015), it is of no use to try to understand why the rest of the system gives wrong answers.

#18 Updated by Gianluca Petrillo over 3 years ago

  • Blocked by Bug #16015: Dual phase detector geometry dunetpc/gdml/protodunedphase.gdml not correctly loaded added

#19 Updated by Gianluca Petrillo over 3 years ago

I was trying to understand the detector by reading how LArSoft sees the detector.
It sees it wrong.
Until the issue with the geometry description is not fixed (issue #16015), it is of no use to try to understand why the rest of the system gives wrong answers.

#20 Updated by Andrea Scarpelli over 3 years ago

Gianluca: the standard configuration files I am using are those made for protoduneDP. Their names are standard_g4_protodunedp.fcl and standard_detsim_protodunedp.fcl. and they are both in dunetpc/fcl/protodunedp. The geometry error you displayed before doesn't occur if you use these files.

#21 Updated by Dorota Stefan over 3 years ago

"Reco problem" has been solved by pulling larcore so I will not open a separate ticket. Thanks for help and apologizes for distraction.

#22 Updated by Tingjun Yang over 3 years ago

The problem did not exist in v06_27_00. It first showed up in v06_28_00. According to the release notes:
https://cdcvs.fnal.gov/redmine/projects/larsoft/wiki/ReleaseNotes062800
the biggest change was the merge of feature/gp_protoDUNEDP_trueOrientation in both larcore and dunetpc.

#23 Updated by Tingjun Yang over 3 years ago

I see Gianluca changed the following file to change the detector rotation:
https://cdcvs.fnal.gov/redmine/projects/dunetpc/repository/diff/dune/Geometry/gdml/generate_dunedphase10kt_v1.pl?utf8=%E2%9C%93&rev=ab2fe3426959685008c24cd7b3fb599a9ddef65a&rev_to=160f6c83d1f829e4038b05eea2e97a9bff559798
However, I don't think anyone generated new gdml files to reflect this change.

Also the change was made to the FD dualphase geometry. What about protoDUNE dualphase geometry?

#24 Updated by Gianluca Petrillo over 3 years ago

Andrea Scarpelli wrote:

Gianluca: the standard configuration files I am using are those made for protoduneDP. Their names are standard_g4_protodunedp.fcl and standard_detsim_protodunedp.fcl. and they are both in dunetpc/fcl/protodunedp. The geometry error you displayed before doesn't occur if you use these files.

Whoops... I missed the essential "dp" in the path.
To clarify: I believe the observations which led me to open issue #16015 are still valid, as I was using the geometry configured by Andrea's attached FHiCL file.
I have now run with the correct G4 configuration (or so I believe), and I do see the messages Andrea refers to, and I do think those are not normal.

I also think those might be caused by the wrong ordering of the wire.
The new geometry code might be relying more on the GDML description than the older one did, and that might explain why an existing problem in wire ordering in v06_27_00 would not manifest in a wrong simulation.
I am investigating that, although it's hard because of the "infinite" time it takes to ROOT to compute the full weight of the detector (which in that version was not optional like it is now).

#25 Updated by Tingjun Yang over 3 years ago

Gianluca is right. This does seem to be caused by the wire sorting.

In the current version (v06_28_01), the U wires are in the z direction and the V wires are in the y direction. Apparently the channel sorting function could not handle this geometry.

What are the expected wire orientations?

#26 Updated by Robert Sulej over 3 years ago

Hi Tingjun,

In reality, and in the target version of geometry, it will be along Z and X axes (perpendicular to each other, both horizontal). It is still a long way to make geometry and all the sim/reco code functional in this desired orientation. For the transition time we have to deal with the rotated geometry, with wires along Z and Y axes (both in vertical plane).

#27 Updated by Tingjun Yang over 3 years ago

Simulation and reconstruction should work with develop version of dunetpc now.

#28 Updated by Andrea Scarpelli over 3 years ago

This issue seems solved (see the event display). Thank you very much

#29 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 10 to 100

Marking as resolved after Andrea's comment.

#30 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF