 |
 |
Originally, as Maurik said, the DST maker only wrote Ecal hits associated with a corrected Ecal cluster (i.e. cluster->getCalorimeterHits();) With Maurik's changes, all Ecal hits written to the DST now come from the collection "EcalCalHits". The cluster time comes from the seed hit of the cluster so if there was a correction applied to the seed that wasn't propagated to the original EcalCalHits collection, then this might be the issue. This might be the reason why I didn't write all of the Ecal hits to the DST maker to begin with but I don't remember. Maurik, did you look at distributions of Ecal clusters variables before and after your changes in order to make sure that there wasn't any changes? If not, then we should revert all of your changes and do these checks. On Sep 20, 2016 9:59 AM, "Sebouh Paul" <[log in to unmask]> wrote: > To get technical, I did not look at the recon LCIO files directly, but > rather generated DQM from them. And the DQM did not look different between > the two files. Now what Nathan had suggested was that possibly the DST > maker is reading the hits from a different collection than it was reading > from before, for instance uncallibrated hits instead of callibrated hits? > > On Tue, Sep 20, 2016 at 11:21 AM, Omar Moreno <[log in to unmask]> > wrote: > >> Just to make sure, this behavior isn't observed looking at the recon LCIO >> files correct? >> >> On Sep 20, 2016 7:59 AM, "Sebouh Paul" <[log in to unmask]> wrote: >> >>> Without pulse fitting, or the mode7 emulation, all of the hit times >>> would be at times that are multiples of 4 ns, corresponding to the time of >>> the first sample crossing the threshold. However, we use a pulse fitting >>> algorithm, which improves our resolution on timing for the hit, as well as >>> time-walk corrections. If a fit fails the pulse fitting and the mode-7 >>> emulation, then we use the time of the first sample that crosses the >>> threshold. In the "bad files" we see a lot of low energy hits with >>> multiples of 4ns times, which probably failed both these two methods of >>> time reconstruction. >>> >>> There is also another thing in here I forgot to mention: there is also >>> a shift in the timing window of when multiple hits are, between the "bad" >>> files and the "good" files. What i mean is, you'll see a peak in hit time, >>> corresponding to the trigger window. This peak is shifted between files >>> generated using the old version of the DST and the new version. >>> >>> On Tue, Sep 20, 2016 at 10:47 AM, Maurik Holtrop <[log in to unmask] >>> > wrote: >>> >>>> Hello Sebouh, >>>> >>>> There was a bug in the DST maker where it would only write ECAL hits >>>> that were part of a cluster, and if a hit appeared in two clusters, it >>>> would write that hit twice. This is not the correct behavior. I fixed this >>>> in Issue44 (https://github.com/JeffersonLab/hps-dst/issues/44) and >>>> then merged to master. >>>> >>>> So, #1, is because now the unrelated and out of time hits are also in >>>> the DST. >>>> I don’t think this explains #2. >>>> #3 Since the FADC samples at 250Mhz, I would expect all ECAL hit times >>>> to be at multiples of 4ns, but perhaps I am missing something? >>>> >>>> Best, >>>> Maurik >>>> >>>> On Sep 20, 2016, at 9:37 AM, Sebouh Paul <[log in to unmask]> wrote: >>>> >>>> Has anyone made modifications to the DST maker since pass0 began in >>>> June 6? Nathan ran recon and DST maker on some files at the beginning of >>>> August, and there are some problems with the DST files produced: >>>> >>>> 1) 1.5x more ecal hits per event than in DST files generated in pass0. >>>> >>>> 2) two cluster time difference has a much larger sigma than usual. >>>> 3) many ecal hits have hit times that are exact multiples of 4 ns. >>>> >>>> I ran DQM on the corresponding LCIO files, and saw none of these >>>> effects, so the problem must be in the DST maker. >>>> >>>> thanks. >>>> >>>> ------------------------------ >>>> >>>> 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 >>> >> > ######################################################################## 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