 |
 |
Yes, it looks correct from the database dump on the Confluence page. -----Original Message----- From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Nathan Baltzell Sent: Thursday, December 04, 2014 7:58 PM To: hps-software Subject: Re: ECAL channel mapping convention Can you please confirm that x,y,id in ecal_channels is 100% correct. -Nathan On Dec 4, 2014, at 10:27 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: > Here's complete documentation on the ECAL channel mapping conventions and database table: > > https://confluence.slac.stanford.edu/display/hpsg/ECAL+Channel+Mapping > +Conditions > > I am pretty sure it is fine because I've spot checked the information on a number of different channels in the database, and it is correct. > > I've also been using it for cosmic analysis/clustering on the raw data, which would not work if it was completely off. > > In other words, the MIP "tracks" I reconstruct look fine in the event display, and this would not be the case if the channel mapping was done incorrectly. > > -----Original Message----- > From: Nathan Baltzell [mailto:[log in to unmask]] > Sent: Thursday, December 04, 2014 6:33 PM > To: McCormick, Jeremy I. > Cc: Stepan Stepanyan; hps-software > Subject: Re: ECAL channel mapping convention > > Stepan, > There is no problem. Jeremy's channel_id is a single integer that uniquely defines the calorimeter channel. Believe it or not, ECal has actually never officially had that before. > > Jeremy, > Please confirm that x,y,id in ecal_channels in the database is 100% correct according to your convention, not just that it "looks" like it is correct. Then print x,y,id mapping in a table, along with your emailed description, on confluence. > > -Nathan > > > > On Dec 4, 2014, at 9:08 PM, "McCormick, Jeremy I." <[log in to unmask]> wrote: > >> If it is considered adequate, then we can leave it. I just wanted to make sure because once we start to add a lot of conditions sets like pedestal calibrations per run, we are essentially stuck with it I think. >> >> -----Original Message----- >> From: Stepan Stepanyan [mailto:[log in to unmask]] >> Sent: Thursday, December 04, 2014 5:58 PM >> To: McCormick, Jeremy I.; Nathan Baltzell >> Cc: hps-software >> Subject: Re: ECAL channel mapping convention >> >> Jeremy, >> >> What is exactly problem? I am not sure I follow the reasoning. >> Unless it makes coding hardships why change something that most of ECal people already are used to. >> >> Stepan >> >> On 12/4/14, 5:43 PM, McCormick, Jeremy I. wrote: >>> Hi, >>> >>> It looks to me that what is in the database for the ECAL channel mapping has the following convention... >>> >>> 1) The mapping is stored in the ecal_channels table which has these fields. >>> >>> channel_id - sequential channel ID (1 to 442) x - geometric X index >>> (-23 to 23 with no 0) y - geometric Y index (-5 to 5 with no 0) >>> crate >>> - crate number (1 or 2) slot - slot number (3 to 20) channel - >>> channel number (0 to 15) >>> >>> 2) channel_id 1 starts at x = -23 and y = 5, channel_id 2 at x = =22 and y = 5, etc. >>> >>> 3) channel_id 47 is the first in the next row and it is x = -23 and y = 4. >>> >>> So going from the diagram here on page 7 labeled "FADC CHANNEL MAPPING". >>> >>> https://wiki.jlab.org/hps-run/images/f/f4/Ecal_manual_annex.pdf >>> >>> The channel ID numbering convention is sequentially across from the upper right (x = -23) to the left (x = 23). When you get to the next row (y = 4), you go back to -23 again. >>> >>> Convention is the same for the bottom. >>> >>> So essentially the channels are ordered sequentially based on their row first (positive to negative or 5 to -5), then their column (negative to positive or -23 to 23). >>> >>> Yes, that's probably a bit strange to not have them follow the same convention! >>> >>> It isn't necessarily set in stone so if it makes sense to use something else then we can do so. There aren't actually too many valid conditions in there right now for the Eng Run so now would be the time to change it if something else is preferable. Maybe the ordering should actually use positive to negative for both x and y to make it less confusing. >>> >>> Hope that makes sense! >>> >>> Thanks. >>> >>> --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 > > ###################################################################### > ## > 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