Print

Print


Yes, slot 20, channels 13-15 are not calorimeter channels.

crate slot channel
1 20 13 = unused
1 20 14 = unused
1 20 15 = LED clock trigger
2 20 13 = bottom cosmic PMT
2 20 14 = top cosmic PMT
2 20 15 = unused

Only the two PMTs are useful offline.  Their coincidence is the cosmic trigger.
In our current DAQ configuration for cosmics, raw mode and a PMT threshold
that probably can be increased, so far some offline cuts must be done on the
PMT pulses to cleanly select cosmics.

-Nathan




On Nov 6, 2014, at 5:28 AM, Gabriel CHARLES <[log in to unmask]> wrote:

> Yes, I could see this message too.
> 
> Le 2014-11-06 11:25, Andrea Celentano a écrit :
>> Hi,
>> I runned this test, and I got errors like:
>> created LCSim event #53
>> Crate 1, slot 20, channel 13 not found in map
>> Crate 1, slot 20, channel 14 not found in map
>> Crate 2, slot 20, channel 13 not found in map
>> Crate 2, slot 20, channel 14 not found in map
>> Crate 2, slot 20, channel 15 not found in map
>> Did this happen also to you?
>> I know what is going on here:
>> - These DAQ channels are connected to trigger PMTS in the ECAL, and
>> they're not define in the ECAL daq map (since they do not match any
>> ecal channel)
>> - In the past, I tried to find a hack for this, by defining in the daq
>> map a correspondence between these DAQ channels and some non-existing
>> crystals (for example, using ix=0)
>> - This still does not work, because, when creating the lcio event,
>> there's correspondence between these "fake crystals" and the
>> detector-related information
>> --> One would have also to "hack" the detector description and add
>> these "fake crystals". However, I do not know if this is a good idea.
>> What I did in the commissioning branch was to modify the
>> EcalEvioReader class, skipping the data for these DAQ channels
>> (methods makeIntegralHits / makePulseHits).
>> I see that this modification was not moved to the trunk: this is
>> probably ok, since the solution I found was only a temporary
>> work-around.
>> Best,
>> Andrea
>> Il 11/06/2014 12:47 AM, McCormick, Jeremy I. ha scritto:
>>> Hi,
>>> Today I was able to generate LCIO data from the current ECAL EVIO output, using the HPS Java trunk distribution jar.  (Thanks mostly to updates from Sho for Engineering Run compatibility.)
>>> Basically, this just includes the RawCalorimeterHit collections with the IDs and ADC values.
>>> You can test this by running:
>>> cd trunk/evio; mvn test -Dtest=LCSimEngRunEventBuilderTest
>>> It will generate an LCIO file with a few events in it at:
>>> target/test-output/LCSimEngRunEventBuilderTest/LCSimEngRunEventBuilderTest_output.slcio
>>> Right now I am using mostly “dummy” db conditions to get this working.  I know that the pedestal/noise values definitely need to be updated in the database.  Gains are all set to 1 for now.
>>> Any comment/questions on the output can go here:
>>> https://jira.slac.stanford.edu/browse/HPSJAVA-275
>>> Next I’m going to try and get the new event builder working in the monitoring application...
>>> —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
> 
> -- 
> Gabriel CHARLES
> Institut de Physique Nucléaire d'Orsay
> 
> ########################################################################
> 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