HPS-SOFTWARE Archives

Software for the Heavy Photon Search Experiment

HPS-SOFTWARE@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"McCormick, Jeremy I." <[log in to unmask]>
Reply To:
Software for the Heavy Photon Search Experiment <[log in to unmask]>
Date:
Wed, 26 Nov 2014 16:31:07 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (114 lines)
Thanks for the feedback, Stepan.

There is also the individual gain scaling calibration by channel.  I assume this condition is used for real data?  Or perhaps you meant or assumed ADC/GeV is assignable/scalable on a per crystal basis?  (This is my understanding from talking with Nathan about this.)

The existing, detailed equation in LCSim is probably for Monte Carlo analysis, and it works well there when converting sim hits to simulated raw data.  The real detector response with the current hardware/DAQ is quite different we are discovering!  I also probably jumped the gun in expecting accurate energy calibration per crystal from the raw mode cosmic data.  We’re simply not far along to do this yet, and like you said we need electron events to do this properly...

On Nov 26, 2014, at 3:24 AM, Stepan Stepanyan <[log in to unmask]> wrote:

> Hello Nathan and Jeremy,
> 
> This rigorous normalization is useful when you design the thing and want to
> understand your detector parameters. For ECal reconstruction all we need are
> two numbers, pedestal and ADC/GeV conversion factor that should come from
> calibration with a physics event. No need to bother with splitter, light collection
> efficiency, ...
> 
> Regards, Stepan
> On 11/25/14, 9:44 PM, McCormick, Jeremy I. wrote:
>> Forgot to CC this to list....
>> 
>> -----Original Message-----
>> From: Nathan Baltzell [mailto:[log in to unmask]]
>> Sent: Tuesday, November 25, 2014 4:59 PM
>> To: McCormick, Jeremy I.
>> Cc: Andrea Celentano; Holly Vance; Uemura, Sho; Gabriel Charles
>> Subject: Re: HPS Java energy conversion code
>> 
>> Thanks Jeremy,
>> 
>>> gainFactor = 2.0 / (Math.pow(2, nBit) - 12) / 15.0545;
>> 
>> That file you quoted actually has this:  2 / (2^12-1) / 15.0545.
>> At least it did on Nov 20.  The 2 (2^12-1) is ADC range in V (ADC).  The 15 looks to be an expectation of V-s/GeV response.
>> 
>> In our current setup, adjusted for the splitter:
>> maxVolt is now 1.0 instead of 2.0.  (The numerator in the above equation should be using that static variable but isn't).  And now we need an additional factor of 3/2 for the 1:2 TDC:ADC split.
>> 
>> Is 40% surfRatio between APDs and crystals still correct?
>> I thought it was much improved.
>> 
>> ecalReadoutPeriod is 4ns.  That is still correct.  But units on the
>> 15 is commented as something per second.  Probably that is ok (no way we are off by 10^9), and either I missed the explicit unit conversion or its squirreled away somewhere.
>> 
>> My feeling is that all this rigorous normalization is very nice to have physical units, but not necessary.  In the end, the gain calibration is really just a number based on real data with units GeV/ADC.  Ok, maybe it is good to have it rigorous for comparison with simulation ....
>> 
>> -Nathan
>> 
>> 
>> 
>> 
>> 
>> 
>> On Nov 25, 2014, at 6:02 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote:
>> 
>>> Hi,
>>> 
>>> Here's the information about what is in LCSim right now for ADC to energy conversion.
>>> 
>>> (All file locations are relative to the HPS Java trunk directory.)
>>> 
>>> The main Driver is here.
>>> 
>>> ecal-recon/src/main/java/org/hps/recon/ecal/EcalRawConverterDriver.jav
>>> a
>>> 
>>> This actually uses the following class to perform the conversion to energy.
>>> 
>>> ecal-recon/src/main/java/org/hps/recon/ecal/EcalRawConverter.java
>>> 
>>> There are several different algorithms there for doing the conversion, but the one being used I think is the following.
>>> 
>>> gain * adcSum * gainFactor * ecalReadoutPeriod;
>>> 
>>> where
>>> 
>>> adcSum = pedestal subtracted ADC sum
>>> 
>>> gain = individual channel gain factor
>>> 
>>> The gainFactor and ecalReadoutPeriod are defined in
>>> 
>>> ecal-recon/src/main/java/org/hps/recon/ecal/ECalUtils.java
>>> 
>>> where
>>> 
>>> gainFactor = 2.0 / (Math.pow(2, nBit) - 12) / 15.0545;
>>> 
>>> ecalReadoutPeriod = 4.0
>>> 
>>> When this is applied to the current cosmic data, I get some pretty wild crystal energy estimates ranging between -1.0 and 1.0 GeV, but as I understand it these should be more like Gaussian distributions around 0.
>>> 
>>> Right now, Nathan says the gains are too high by a factor of 4.  Getting calibrated channel gains in the conditions system should correct this problem.
>>> 
>>> I'll send along in another email a steering file you can use to test this conversion algorithm.  I also have some plots too which I'll generate and send out as a .root file.
>>> 
>>> --Jeremy
>> ########################################################################
>> Use REPLY-ALL to reply to list
>> 
>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
> 
> ########################################################################
> Use REPLY-ALL to reply to list
> 
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1

ATOM RSS1 RSS2