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