Incorrect track reconstruction from restG4 events

REST version : v2.2.18.
REST commit : 368fcd4f.

Hi,

I have already made a post regarding TRestMesh/TRestFastHitsToTrackProcess here:

I am using the same setup and configuration files as before.
Trying to reconstruct 100 electron restG4 events I use TRestHitsToTrackProcess, not TRestFastHitsToTrackProcess as in the previous post.
In addition, I am using such a list of processes:

  • TRestG4toHitsProcess
  • TRestElectronDiffusionProcess
  • TRestSmearingProcess
  • TRestHitsToSignalProcess
  • TRestSignalToHitsProcess
  • TRestHitsToTrackProcess
  • TRestTrackReductionProcess
  • TRestTrackPathMinimizationProcess
  • TRestTrackReconnectionProcess
    After processing restG4 events I have found that several track projections are reconnected incorrectly. For example, like this:
    image
    image
    I thought before that such problem could be resolved by modifying maximumDistance parameter in TRestTrackReductionProcess, but it is not present in this class anymore and I am not sure which parameter is responsible for this issue.
    Is there is a possibility to track down this kind of bugs?

Thank you in advance.

P.S. There are all the files I use:
configFile_G4Hits_To_Track.rml (5.1 KB)
Run00047_electron2_2MeV_particle_gen.root (3.3 MB)
G4_gen_e.rml (5.4 KB)
geometry.zip (13.9 KB)
Panda_140kg.root (3.7 MB)

Hi Andrii, which graphs you identify as badly reconstructed? Top-right and Bottom-Left?

Yes, these graphs are problematic.
I’ve forgot to attach one more file, sorry.

processFile_general.rml (34.0 KB)

The reconstruction is not fully working 100% of the times. However, in this case I would say the problem with the non-physical connection on top-right and bottom-left plots has a straight forward solution.

Probably, adding to the TRestTrackReconnectionProcess an additional processing that places the hits which define the longest distance to the extreme hits, first and last hit.

So, if the longest distance is between hit N and hit N+1, just shift the hits position inside the array so that hit N corresponds to the latest hit Nmax, and N+1 hit corresponds to hit 0. Does that improve the result on those events?

Doing that should minimise the distance measured between hit 0 and Nmax, for all events.

I remember doing something like that at some point, but not reflected finally on the repository.

The blob finding algorithm will allow some flexibility for some nodes up and down in order identify the blob with the highest charge. This mitigates a bit the error of not properly finding the physical track.

But of course, this might be improved. Could you try adding the algorithm to TRestTrackReductionProcess so that it minimizes the open-loop distance from hit 0 to N?

Thank you!

I will try and tell you what I achieved.