Project

General

Profile

Feature #17804

Provide a way to associate MCParticles between generator and G4 steps

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

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

100%

Estimated time:
Spent time:
Experiment:
LArSoft
Co-Assignees:
Duration:

Description

Feature would greatly facilitate selection of MC truth of interesting particles which are distinguishable at the generator step, but the distinction is lost at G4 step. E.g. in ProtoDUNE we use two process names in the generator of beam particles: "primary" and "primaryBackground"; process name is changed for these particles to "primary" by G4 step, in http://nusoft.fnal.gov/larsoft/doxsvn/html/ParticleListAction_8cxx_source.html (around line 148), and finding the interesting particles become complicated (comparison of momenta etc).

For ProtoDUNE purposes it would be enough to propagate the process name from the generator, but Gianluca says it may break users codes.

More generic solution suggested by Gianluca would be to add a data product allowing for an association of particles at both ends. I believe that with a helper class it can be implemented in such a way that user is accessing product(s) created by G4 only and does not need to know what are the genrators.

Another option could be to encode the information in MCParticle.


Related issues

Blocked by NuTools - Feature #18716: G4Helper: store the index of the true particle within MCTruth in the primary particle informationClosed01/10/2018

Associated revisions

Revision 83be239d (diff)
Added by Gianluca Petrillo over 2 years ago

LArG4 now saves the index of the original particle in its MCTruth

This solves issue #17804.

NOTE: this solution requires solution of issue #18716 (branches feature/gp_Issue18716 of nusimdata and nutools).

Revision 98e48485 (diff)
Added by Gianluca Petrillo over 2 years ago

LArG4 now saves the index of the original particle in its MCTruth

This solves issue #17804.

NOTE: this solution requires solution of issue #18716 (branches feature/gp_Issue18716 of nusimdata and nutools).

Revision 3fbc87f1 (diff)
Added by Gianluca Petrillo over 2 years ago

Added infrastructure for new association.

This is in support for resolution of issue #17804.

History

#1 Updated by Lynn Garren about 3 years ago

  • Category set to Simulation
  • Status changed from New to Accepted

Since much of this code is in nutools and nusimdata, we should ask NOvA how they handle this problem.

#2 Updated by Robert Sulej about 3 years ago

Who could be a good person for the contact? (I know a few but random members of NOvA)

#3 Updated by Gianluca Petrillo about 3 years ago

Adding Jason Stock to the loop.
BackTracker can already connect a simb::MCParticle to a simb::MCTruth. This may be a starting point.

#4 Updated by Jason Stock about 3 years ago

So, I would have two things to contribute immediately.

First, I think that G4's assumption that the process name for all primaries should be "primary" is a bad one. It has always bothered me that we stomp on the process name.

Second, unfortunately there are multiple spots in the code the expect the process name of all "primaries" to be "primary". It would not be trivial to change.

Now let me ask a couple questions.

First, if I understand correctly, what you need is a way to say PreG4 MCParticle X is the same as PostG4 MCParticle Y, right?

Second. I am in the middle of a redesign of the backtracker, and as the first step I have factored out all functions that deal only with generation and g4 results in to a new service called the ParticleInventory (available as feature/JStock_ParticleInventory). Could some of those relationships do what you are asking about?

#5 Updated by Katherine Lato almost 3 years ago

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

#6 Updated by Gianluca Petrillo almost 3 years ago

  • Blocked by Feature #18716: G4Helper: store the index of the true particle within MCTruth in the primary particle information added

#7 Updated by Gianluca Petrillo almost 3 years ago

I have chosen the approach of saving the index of the primary particle in the metadata of the simb::MCParticle/simb::MCTruth association.
The underlying information is lost in the translation from simb::MCTruth into Geant4.
Feature request #18716 is open to relay the missing information.

#8 Updated by Gianluca Petrillo almost 3 years ago

  • Status changed from Assigned to Work in progress

#9 Updated by Jason Stock over 2 years ago

I am pinging this ticket to ask about what information we may want functionality we may want to add to the ParticleInventory to utilize this new information Gianluca is adding to the MCParticle/MCTruth Association. I plan on doing some code maintenance soon (Mostly adding/updating documentation), and could add a couple new functions if helpful.

#10 Updated by Gianluca Petrillo over 2 years ago

  • % Done changed from 0 to 90

A solution has been pushed as branch feature/gp_Issue17804 in lardataobj and larsim.
This requires the solution to the blocking issue to be also integrated (in nutools/nusimdata).


Edit: fixed branch names.

#11 Updated by Gianluca Petrillo over 2 years ago

  • Status changed from Work in progress to Resolved
  • % Done changed from 90 to 100

It is now merged into LArSoft v06_74_00.

#12 Updated by Gianluca Petrillo over 2 years ago

An unwanted feature where all the primary particles were saved in the particle list regardless of volume filtering has been removed.
The fix was pushed in larsim develop shortly after v06_74_01 as commit larsim:9ff453a (the commit message reports a typo'ed issue number).

#13 Updated by Jason Stock over 2 years ago

Will this be fcl toggle-able in future releases?

#14 Updated by Gianluca Petrillo over 2 years ago

  • Status changed from Resolved to Closed

#15 Updated by Gianluca Petrillo over 2 years ago

Jason Stock wrote:

Will this be fcl toggle-able in future releases?

If requested.



Also available in: Atom PDF