Difference: PulseShapeStudies (1 vs. 4)

Revision 42011-04-22 - PeterWinter

Line: 1 to 1
 
META TOPICPARENT name="MuLan.SystematicStudies2006"
Deleted:
<
<

-- KevinLynch - 30 Apr 2008

Pulse Shape Studies

We have claimed from the beginning, based on E821 experience, that we can use a single pulse shape for fitting pulses (operationally, David and Kevin both use a single pulse shape per channel, I think) at all times and for all amplitudes. One must obviously check this claim. This can be done just once, as it is (mostly:-) ) a function of the raw data, not the pulse fitter.

We must show that pulse shapes are identical, or that the differences don't matter, over:

  • raw pulse amplitude
  • raw pulse pedestal
  • by time in fill
  • by time on island
  • across the run
  • by cuts on pulses that enter into the shape calculations

The "right" way to do this is to study the pulse structure plots (described in the links in elog:Analysis2006Data/48) for systematic differences across runs and such.

In elog:Analysis2007Data/29, we see that the pulse shapes (for a certain set of cuts) don't differ much between a random set of runs in 2006 (about 17GiB of data) and a similarly sized random set of runs in 2007 (about 20GiB of data). This analysis is qualitative, but probably sufficiently good to show that there are no systematic lifetime shifts to be expected during a given run from pulse shape changes alone (since pulse shapes defined over all chosen pulses are stable across a really long shutdown and multiple detector moves and electronics and firmware changes).

As for the rest of these conditions, many more pulses need to be processed. Consider, for instance, studying pulse shapes across the fill (arguably the most important possible effect). Splitting the fill into 10 "buckets" of roughly 1 lifetime each, and processing over 20GiB of 2007 data gives roughly 4000 pulses/channel passing very generous cuts in the late time tail. With 99 bins/tick, this gives roughly 40 events per bin, far from adequate for serious study ... I'd be much happier with 1000 events/channel, as the same bin variation appears to be larger than gaussian. So I need roughlly 25 times as much data as I've processed to date for these studies. But the good news is that these pulse shape studies are quick: on my 2.2 GHz Core 2 Duo based laptop with 3GiB of RAM, where I see roughly 84% CPU utilization, it takes roughly 50 minutes to generate 350x10x3 pulse structure histograms ... and comparison is (computationally speaking) free. So, I would only need about 25x2x~10 = <500 hours on my laptop. How exactly that maps to NCSA isn't clear to me, since I haven't benchmarked my code there yet. But it should be the same order of magnitude, I would think, based on the node specifications.

Proper comparison will require a small pile of code that I haven't written, but it is all straightforward Monte Carlo generation and histogram comparison code, using well known algorithms. The comparisons themselves can be easily done off-NCSA on my laptop during my daily train ride on the train.

 \ No newline at end of file
Added:
>
>
Please go to https://muon.npl.washington.edu/twiki/bin/view/Main/PulseShapeStudies
 \ No newline at end of file

Revision 32009-03-06 - DavidWebber

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="SystematicStudies2006"
>
>
META TOPICPARENT name="MuLan.SystematicStudies2006"
 

Revision 22008-04-30 - KevinLynch

Line: 1 to 1
 
META TOPICPARENT name="SystematicStudies2006"
Line: 23 to 22
  The "right" way to do this is to study the pulse structure plots (described in the links in elog:Analysis2006Data/48) for systematic differences across runs and such.
Changed:
<
<
In elog:Analysis2007Data/29, we see that the pulse shapes (for a certain set of cuts) don't differ much between a random set of runs in 2006 (about 17GiB of data) and a similarly sized random set of runs in 2007 (about 20GiB of data). This analysis is quantitative, but probably sufficiently good to show that there are no systematic lifetime shifts to be expected during a given run from pulse shape changes alone (since pulse shapes defined over all chosen pulses are stable across a really long shutdown and multiple detector moves and electronics and firmware changes).
>
>
In elog:Analysis2007Data/29, we see that the pulse shapes (for a certain set of cuts) don't differ much between a random set of runs in 2006 (about 17GiB of data) and a similarly sized random set of runs in 2007 (about 20GiB of data). This analysis is qualitative, but probably sufficiently good to show that there are no systematic lifetime shifts to be expected during a given run from pulse shape changes alone (since pulse shapes defined over all chosen pulses are stable across a really long shutdown and multiple detector moves and electronics and firmware changes).
  As for the rest of these conditions, many more pulses need to be processed. Consider, for instance, studying pulse shapes across the fill (arguably the most important possible effect). Splitting the fill into 10 "buckets" of roughly 1 lifetime each, and processing over 20GiB of 2007 data gives roughly 4000 pulses/channel passing very generous cuts in the late time tail. With 99 bins/tick, this gives roughly 40 events per bin, far from adequate for serious study ... I'd be much happier with 1000 events/channel, as the same bin variation appears to be larger than gaussian. So I need roughlly 25 times as much data as I've processed to date for these studies. But the good news is that these pulse shape studies are quick: on my 2.2 GHz Core 2 Duo based laptop with 3GiB of RAM, where I see roughly 84% CPU utilization, it takes roughly 50 minutes to generate 350x10x3 pulse structure histograms ... and comparison is (computationally speaking) free. So, I would only need about 25x2x~10 = <500 hours on my laptop. How exactly that maps to NCSA isn't clear to me, since I haven't benchmarked my code there yet. But it should be the same order of magnitude, I would think, based on the node specifications.

Revision 12008-04-30 - KevinLynch

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SystematicStudies2006"

-- KevinLynch - 30 Apr 2008

Pulse Shape Studies

We have claimed from the beginning, based on E821 experience, that we can use a single pulse shape for fitting pulses (operationally, David and Kevin both use a single pulse shape per channel, I think) at all times and for all amplitudes. One must obviously check this claim. This can be done just once, as it is (mostly:-) ) a function of the raw data, not the pulse fitter.

We must show that pulse shapes are identical, or that the differences don't matter, over:

  • raw pulse amplitude
  • raw pulse pedestal
  • by time in fill
  • by time on island
  • across the run
  • by cuts on pulses that enter into the shape calculations

The "right" way to do this is to study the pulse structure plots (described in the links in elog:Analysis2006Data/48) for systematic differences across runs and such.

In elog:Analysis2007Data/29, we see that the pulse shapes (for a certain set of cuts) don't differ much between a random set of runs in 2006 (about 17GiB of data) and a similarly sized random set of runs in 2007 (about 20GiB of data). This analysis is quantitative, but probably sufficiently good to show that there are no systematic lifetime shifts to be expected during a given run from pulse shape changes alone (since pulse shapes defined over all chosen pulses are stable across a really long shutdown and multiple detector moves and electronics and firmware changes).

As for the rest of these conditions, many more pulses need to be processed. Consider, for instance, studying pulse shapes across the fill (arguably the most important possible effect). Splitting the fill into 10 "buckets" of roughly 1 lifetime each, and processing over 20GiB of 2007 data gives roughly 4000 pulses/channel passing very generous cuts in the late time tail. With 99 bins/tick, this gives roughly 40 events per bin, far from adequate for serious study ... I'd be much happier with 1000 events/channel, as the same bin variation appears to be larger than gaussian. So I need roughlly 25 times as much data as I've processed to date for these studies. But the good news is that these pulse shape studies are quick: on my 2.2 GHz Core 2 Duo based laptop with 3GiB of RAM, where I see roughly 84% CPU utilization, it takes roughly 50 minutes to generate 350x10x3 pulse structure histograms ... and comparison is (computationally speaking) free. So, I would only need about 25x2x~10 = <500 hours on my laptop. How exactly that maps to NCSA isn't clear to me, since I haven't benchmarked my code there yet. But it should be the same order of magnitude, I would think, based on the node specifications.

Proper comparison will require a small pile of code that I haven't written, but it is all straightforward Monte Carlo generation and histogram comparison code, using well known algorithms. The comparisons themselves can be easily done off-NCSA on my laptop during my daily train ride on the train.

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback