Flash FInder Timing Offset not handled correctly
Flash finder needs to update its understanding of beam time, to properly handle offsets given in runtime fhicl files.
This does not affect simulation, but should be fixed before running big reco jobs.
#2 Updated by Erica Snider over 6 years ago
- Status changed from New to Assigned
Please start a hotfix branch using 'git flow hotfix start xxxx' where 'xxxx' is something descriptive, make your changes there, test it, then publish the hotfix branch. Lynn can then make the release.
Also, please let us know how to test this so that we can see that the patch worked.
#3 Updated by Kazuhiro Terao over 6 years ago
- File Screen Shot 2014-03-05 at 6.54.41 AM.png Screen Shot 2014-03-05 at 6.54.41 AM.png added
- Category set to Reconstruction
- Priority changed from Urgent to Immediate
- % Done changed from 0 to 80
I have a fix in my local installation (under hotfix as suggested).
As some of you already know it concerns the flash timing with respect to beam timing.
I attach a flash time distribution (weighted by PE) after I applied a fix.
Original input sample to make this plot is GENIE+CRY 1 event generated by Tingjun
which is generated using a fcl file:
The input was further processed with ubooneoffline 2D reco code:
larana/OpticalDetector/OpFlashAna_module.cc is then used to generate this plot.
A driver fcl file to run OpFlashAna can be found here:
Note that the X-axis label is not correct in the plot. The X-axis is # of time ticks in 64MHz and NOT in [ns].
The distribution spans the expected timing from -3.2ms to +3.2 ms as a result of fix.
I am a bit worried about a long period of crowded flash distribution after beam, spanning from 0 to +3.2 ms.
Once Ben confirm this distribution looks reasonable I will merge and push.
#6 Updated by Kazuhiro Terao over 6 years ago
I agree we do expect light outside beam window. In fact we see some before beam arrives @ T=0.
I think Ben meant that late time period is too long, continuing to the end of readout window (0=>3.2 ms) while it should be micro-seconds.
If you have inputs on what could be wrong, let me know. I only looked at obvious coding mistakes like type conversions and did not focus on physics at all...
#8 Updated by Kazuhiro Terao over 6 years ago
I'll do that check after I finish what I am doing.
Here's a list of things to check:
(0) G4 photon timing
(1) PMT waveform timing (timing conversion from G4 photon to readout clock)
(2) OpHit timing
(3) OpFlash timing
What I showed is (3). I check (0) to (2) first.
#9 Updated by Kazuhiro Terao over 6 years ago
I attach two plots:
(a) G4PhotonTime.gif ... G4 photon time (-3.2 ms to +3.2 ms) distribution
(b) WFStartTime.gif ... PMT readout window start time (beam + cosmic, in PMT clock unit w/o frame, so it spans from 0 to 409600).
You see G4 photon distribution looks more-or-less OK: there are photons arriving before/after beam gate (
T=0) almost equal rate.
I am a bit concerned why no photon arrived between ~-3.2 ms to -2.2 ms ... but ok put that aside for now.
You see PMT readout window start time does not show corresponding G4 photon arrival time before the beam gate arrival time (@ T=204800).
There are peaks that seem to correspond to the cosmics after beam, but there's no big peaks before the beam.
From these observations, unless there's a mistake on my side making these histograms, FlashFinder is working as expected.
Somehow we just have fewer waveforms recorded for cosmics before the beam.
I cannot say with certainty this is a bug but it seems concerning the result is different before and after the beam gate.
So... based on this, I claim my fix for FlashFinder is working. Let me know if you agree, then I will commit.
But then there will be another discussion whether we want to hunt down a reason for these plots. Opinions welcome....
#10 Updated by Kazuhiro Terao over 6 years ago
- File WFTime.gif WFTime.gif added
- File FlashTime.gif FlashTime.gif added
- % Done changed from 80 to 90
OK I hunt down another bug introduced by making beam window larger.
Attaching WFTime plot and flash time distribution (see previous post for axis definition... please read...)
Here's important notes:
() All fix are in OpticalDetector
() detsim needs to run with this fix
(*) reco needs to run with this fix (which is automatically applied if the previous point is satisfied).
@Ben, please share your opinion so I can commit.
Anyone else has a concern / question?
#13 Updated by Lynn Garren over 6 years ago
A new release has been tagged and built based on this hotfix.
It is installed in /grid/fermiapp/products/larsoft (and /grid/fermiapp/uboone/software/products/)
I made the uboonecode release to reduce the overall time before this was available.
The only changes to larsoft and uboonecode are in the list of products they setup.