Problem in Hits or Tracks X &Y in v2.2.14 version

RESTFramework
1

REST version : v2.2.14_dev/v2.2.14
REST commit : f85a5828

I have tried to process a simulation and found that I only have XYZ tracks (XTracks or YTracks are exacly ==0, what was not like that in v2.2.13 version last week). Trying to understand the reason, I have the guess that it could be due to the definition of nHitsX or nHitsY which have been changed in last version(s). These two observables of hitsAna give exactly the same values (same as nHits). I have tried to track back the error in TRestHit.h or TrestHit.cxx, where REST_HitType has been defined, but no chance. Please, could anybody check if this is working properly?
Thanks
Gloria

2

I imagine the problem you are experiencing is the same we are experiencing when processing TREX data.

For TREX data I have created few validation scripts under /macros/pipeline/trex/ that will be run in every push.

The validation was successful when reverting the commit edb40335, where @nkx introduced few updates on TRestHits objects. Those updates need now some revision to pass the validation tests.

Now those validation tests for TREX data produce a green checkmark (at SJTU Gitlab repository) .

10
102392×562 125 KB

Are your problems fixed if you get the latest commit from v2.2.14_dev?

3

I have cloned REST in a new directory. Now I have used REST Version : 2.2.15, REST Commit : 63ee2e54 …and same problem :frowning:

4

We need to identify at which point in the code updates this problem was introduced, could you provide more information about the problem?

Such as:

  • Full output from analysisTree (before/after problem).
  • A minimal set of RMLs that allows us to reproduce the problem.
  • Latest working commit for you.
5

Hi,

  • Before the problem hitsAna_nHitsX, hitsAna_nHitsX and hitsAna_nHits were different spectra.
  • Now all of them are a copy of hitsAna_nHits. Most of the values of tckAna_nTracks_X and tckAna_nTracks_Y were 1 and now they give exactly 0.
  • The observable tckAna_nTracks_XYZwere OFF then and for this reason it doesn’t appear in AnalysisTree, but in the current commit it gives values around 1 (Then, I guess now we are not classifying hits into X and Y hits).
  • No error messages.
  • The full output are in /media/storage/simData/TREXDM/Neon/NeutronCalibration_6bar files Analysis5_Cf252Calibration_6.root (latest working commit of 10th March REST Version : 2.2.14, REST Commit : d8f56051) and Analysis5_Cf252Calibration2_6bar_15e4.root (REST Version : 2.2.15, REST Commit : 63ee2e54).
  • RML files (attached)G4processes.rml (23.3 KB) NeutronCalibration_v2.rml (6.5 KB) restNeonSimManager_v2.rml (5.4 KB) are in /home/gloria//GitLab/TREXDM-REST/G4sims/restProcesses (restNeonSimManager_v2.rml and G4processes.rml) and for the geometry (trexdmgeometry.gdml (44.6 KB) trexdmsetup.gdml (6.2 KB) )
  • Output in both cases are Output_v.2.2.14.txt.txt (6.6 KB) for the first case and Output_v2.2.15.txt.txt (6.3 KB) for the wrong analysis
6

Hi, I found the problem. It took me a while to reproduce the full chain with both versions. Version d8f56051 and version 63ee2e54. And struggle because I got exactly the same results.

Finally, I couldn’t not have guessed the problem without access to the root output files. When I load those files with restRoot I get …

Using the file that is supposed to be right

restRoot /media/storage/simData/TREXDM/Neon/NeutronCalibration_6bar/Analysis5_Cf252Calibration_6.root

Attaching metadata structures...
- md0_TemplateEventProcess (TRestProcessRunner)
- md0_g4Ana (TRestGeant4AnalysisProcess)
- md0_g4ToHits (TRestG4toHitsProcess)
- md0_Ne_electronDiffusion (TRestElectronDiffusionProcess)
- md0_hitsToSignal_Template (TRestHitsToSignalProcess)
- md0_signalToHits (TRestSignalToHitsProcess)
- md0_hitsAna (TRestHitsAnalysisProcess)
- md0_fastHitsToTrack_Template (TRestFastHitsToTrackProcess)
- md0_trackReconnection_Template (TRestTrackReconnectionProcess)
- md0_tckAna (TRestTrackAnalysisProcess)
- md0_TREXDM_v1 (TRestReadout)
- md0_Neon_Isobutane2Pct10_10E3Vcm (TRestGas)

Using the file that is supposed to be wrong

restRoot /media/storage/simData/TREXDM/Neon/NeutronCalibration_6bar/Analysis5_Cf252Calibration2_6bar_15e4.root

Attaching metadata structures...
- md0_TemplateEventProcess (TRestProcessRunner)
- md0_g4Ana (TRestGeant4AnalysisProcess)
- md0_g4ToHits (TRestG4toHitsProcess)
- md0_Ne_electronDiffusion (TRestElectronDiffusionProcess)
- md0_hitsAna (TRestHitsAnalysisProcess)
- md0_fastHitsToTrack_Template (TRestFastHitsToTrackProcess)
- md0_trackReconnection_Template (TRestTrackReconnectionProcess)
- md0_tckAna (TRestTrackAnalysisProcess)
- md0_TREXDM_v1 (TRestReadout)
- md0_Neon_Isobutane2Pct10_10E3Vcm (TRestGas)

As you see the one that is supposed to be right includes the readout through the HitsToSignal and SignalToHits process.

The one that is supposed to be wrong does not include the readout, and therefore the hits have full XYZ information. The data is not splitted in X and Y strips.

Thats it.

Please, make sure the problem is related to the rest version by using exactly the same RML files, and the two suspicious REST installations.

7

I’am not sure Javier. Yes, HitsToSignal and SignalToHits processes were OFF in the wrong file (I was just taking them ‘ON’ and ‘OFF’ to see the impact of this processes and in that case they were ‘OFF’). There is another file ‘Analysis5_Cf252Calibration13_6bar_15e4.root’ processed with 'REST Version : 2.2.14, REST Commit : f85a5828 ’ and HitsToSignal and SignalToHits ‘ON’

Attaching metadata structures…

  • md0_TemplateEventProcess (TRestProcessRunner)
  • md0_g4Ana (TRestGeant4AnalysisProcess)
  • md0_g4ToHits (TRestG4toHitsProcess)
  • md0_Ne_electronDiffusion (TRestElectronDiffusionProcess)
  • md0_hitsToSignal_Template (TRestHitsToSignalProcess)
  • md0_trigger (TRestTriggerAnalysisProcess)
  • md0_signalToHits (TRestSignalToHitsProcess)
  • md0_hitsAna (TRestHitsAnalysisProcess)
  • md0_fastHitsToTrack_Template (TRestFastHitsToTrackProcess)
  • md0_trackReconnection_Template (TRestTrackReconnectionProcess)
  • md0_tckAna (TRestTrackAnalysisProcess)
  • md0_TREXDM_v1 (TRestReadout)
  • md0_Neon_Isobutane2Pct10_10E3Vcm (TRestGas)

And it is not working properly as you can see in the Output2-v2.2.2.14.txt.txt (5.8 KB)
Anyway, now I’ve tried again and produced a new file with v2.2.15 which is OK

8

So, it is working properly.

9

Perhaps was related to what I mentioned at the beginning of the post?

10

For commit f85a5828, this problem could be due to the old version of TRestHitsEvent contained in the input root file. If you re-generate hits event from signal event, the XZ and YZ information should be properly added.

1 Like
11

I see, the bug is in TRestHitsAnalysisProcess. It wipes out the type information when copying the input event to the output event

1 Like