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