From lefebvre@uvic.ca Tue May 11 09:45:08 2004 Date: Fri, 7 May 2004 14:28:23 -0700 (PDT) From: Michel Lefebvre To: Rob McPherson Cc: Tayfun Ince , Alan Astbury , Ian Gable , Michel Lefebvre , Ashok Agarwal , Paul Poffenberger , Richard Keeler , Randy Sobie , Warren Shaw , Tamara Hughes , Margret Fincke-Keeler , Monika Wielers Subject: RE: running LArHECTBAna with Athena 8.0.0 Hi Rob, I have studied your comments very carefully, with a view of our user code TBRootAna. I understand the following issues going from before 7.8.0 to 7.8.0 and up: LArTBCombinedNtup - Run header block m_first_ch not affected first febno value (also smallest) m_last_ch not affected last febno value (also biggest) m_cells_used now contains number of connected cells only The following arrays m_ped_rms, m_ieta, m_phi, m_iz, m_ieta_atlas, m_iphi_atlas, m_iz_atlas are indexed using febno, but they are declared of dimension m_cells_used, which is now too short - Event block m_chan now contains number of connected cells only m_signal now indexed 0 to m_chan-1 instead of febno Note that the first valid value of febno is 1 for the HEC and 0 for the EMEC, for historical reasons, so that TBRootAna accesses m_signal through m_signal[febno] for the EMEC m_signal[febno-1] for the HEC In 1998, Dugan and I implemented your solution 1A to hec_adc, because of complains from our Russian colleagues that ntuples were too big for their computers. For ntuples in ADC, all channels (connected and unconnected ) were output, while if users selected ntuples in nA, then only connected channels were output. The run header ntuple contained an index that mapped the m_signal array index ("ich" in your note) to febno and which had to be used. As you mention, this meant that the ntuple were annoying to use. Given that HEC stand-alone ntuples were pretty small, all this was a real nuisance, and a cause for endless confusion. When Naoko started coding all this, we agreed that we would get rid of this (cleaner, I admit) feature, and would just output ALL channels always. This is why there is no index array in the run header in LArTBCombinedNtup, while there was on in hec_adc. We felt that we could live with the larger ntuples for the HEC-EMEC combined tests (if unconnected channels were not wanted) especially since we thought ROOT could compress ntuples somehow. Comments on the options: > Questions: > > This can be trivially fixed in one of two ways. > You (users of these ntuples) have to choose: > > 1) Make both ntuples consistently use only connected > channels. I can easily do this by switching the > "index" in the run ntuple to use the same style > as the event ntuple. > > This will only work if the user code consistently > uses the run ntuple ieta, iphi and iz for the cell > coordinates (this must be true for everything including > your geometry/mapping stuff). Very hard to implement on the TBRootAna side. TBRootAna does not use the Run header arrays m_ieta, m_phi, m_iz, m_ieta_atlas, m_iphi_atlas, m_iz_atlas at all. But it makes crucial use of m_first_ch, m_last_ch, m_cells_used All the geometry business is treated separately, with all parameters in a ascii files (poor man's database!). > 1A) If you use the "febno" index in your analysis, > I could insert this into the run ntuple. > That would still require some modification in the user > code to access the run ntuple for the index. Possible, but somewhat of a pain to implement. Given that pre 7.8.0 ntuples will not have this index, the TBRootAna code would have to act differently for different versions of the ntuple. Could be hacked in of course, but it would involve some work and some debugging, and backward compatibility would have to be ensured. > > 2) Make both ntuples use the "get_febno()" index. I would > do that by declaring the ntuples up to MAX_ADC instead > of m_cells_used, filling them with dummy values, and > then overwriting the connected channels with their valid > values. > > This will make the ntuples bigger. Something like that would be my favorite option. The dummy values could be zero, and perhaps most of that can be compressed away anyway. MAX_ADC is currently set to 1152. This corresponds to the nominal number of channel read for the EMEC (febno 0 to 1151). This would of course be an overkill for the HEC (which requires 384 for febno 1 to 384). Before 7.8.0, m_signal is declared, for each event, with a size of m_chan, which was different for HEC and EMEC (and equal to the number of channels, connected + unconnected). Ideally, what we need is a way to somehow do the following in LArTBCombinedNtup: - set m_cells_used to the number of channels (connected + unconnected) - set m_chan to the same value (which is different for HEC and EMEC) - fill m_signal using febno as index Then I think we need no change in TBRootAna. Unless I am missing something, Tayfun and Tamara (and me and possibly Marco at SFU) will be the last ones to ever use LArTBCombinedNtup. The only reason why we should perhaps fix it is in case Tayfun and Tamara have to reproduce ntuples that for some reason absolutely require an Athena version above or equal to 7.8.0. If this never happens, then we may not need to change anything. LArTBCombinedNtup may even be retired for later versions of Athena... Ian is now working to ensure that we can run 7.6.0. locally, so we will probably never need to use LArTBCombinedNtup for version 7.8.0 and higher. Let's finalize the discussion next week when I am at CERN. Cheers Michel