Project

General

Profile

Bug #5588

Flash FInder Timing Offset not handled correctly

Added by Wesley Ketchum about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Immediate
Category:
Reconstruction
Target version:
Start date:
03/04/2014
Due date:
% Done:

100%

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

Description

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.

Screen Shot 2014-03-05 at 6.54.41 AM.png (45.2 KB) Screen Shot 2014-03-05 at 6.54.41 AM.png Kazuhiro Terao, 03/05/2014 08:29 AM
G4PhotonTime.gif (13.9 KB) G4PhotonTime.gif Kazuhiro Terao, 03/06/2014 03:07 PM
WFStartTime.gif (19.2 KB) WFStartTime.gif Kazuhiro Terao, 03/06/2014 03:07 PM
WFTime.gif (10.6 KB) WFTime.gif Kazuhiro Terao, 03/06/2014 04:10 PM
FlashTime.gif (17.7 KB) FlashTime.gif Kazuhiro Terao, 03/06/2014 04:10 PM

History

#1 Updated by Wesley Ketchum about 6 years ago

This will need to be a hotfix after it is put in.

#2 Updated by Erica Snider about 6 years ago

  • Status changed from New to Assigned

Hi Kazu,
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.

Thanks!
Erica

#3 Updated by Kazuhiro Terao about 6 years ago

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

/uboone/app/users/tjyang/larsoft_dev/ubfcl/prodgenie_bnb_nu_cosmic_3window_uboone_0_0_gen_0_0_g4.root

which is generated using a fcl file:

/uboone/app/users/tjyang/larsoft_dev/ubfcl/gen/genie/prodgenie_bnb_nu_cosmic_3window_uboone.fcl

The input was further processed with ubooneoffline 2D reco code:

https://cdcvs.fnal.gov/redmine/projects/ubooneoffline/repository/changes/trunk/products/ubfcl/reco/standard_reco_uboone_2D.fcl
to generate recob::Flash.

larana/OpticalDetector/OpFlashAna_module.cc is then used to generate this plot.
A driver fcl file to run OpFlashAna can be found here:

/uboone/app/users/kterao/scratch/ana.fcl

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.

Kazu

#4 Updated by Benjamin Jones about 6 years ago

Hi guys

I replied to Kazu and Wes, but this looks wrong to me. The beam window should be a few microseconds, and late light should also come for a few microseconds. So something is definitely wrong here (but I don't know what).

Ben

#5 Updated by Tingjun Yang about 6 years ago

This is a nu + cosmic overlaid event. Shouldn't we expect light outside the beam window?

#6 Updated by Kazuhiro Terao about 6 years ago

@Tingjun,

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.

@Ben,

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...

#7 Updated by Wesley Ketchum about 6 years ago

Perhaps naive question, but how do you know it's late light and not other cosmic rays?

Can you check on a bnb_nu_3window with no cosmics, and confirm the same problem?

#8 Updated by Kazuhiro Terao about 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.

Kazu

#9 Updated by Kazuhiro Terao about 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.

@ Ben,
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....

Kazu

#10 Updated by Kazuhiro Terao about 6 years ago

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?

Kazu

#11 Updated by Kazuhiro Terao about 6 years ago

  • % Done changed from 90 to 100

Ben gave me a green light. I'll commit this fix asap.

Kazu

#12 Updated by Erica Snider about 6 years ago

  • Status changed from Assigned to Resolved
  • Target version set to v1_00_04_ub01

#13 Updated by Lynn Garren about 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.

New releases:
larana v1_00_04_ub01
larsoft v1_00_04_ub01
uboonecode v1_00_04_ub01

The only changes to larsoft and uboonecode are in the list of products they setup.

#14 Updated by Lynn Garren over 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF