 |
 |
Hi Norman, I agree with this, and I will makes these changes to both EcalClusterIC and HPSEcalClusterIC. -Holly On Tue, Dec 16, 2014 at 10:23 AM, Graf, Norman A. <[log in to unmask]> wrote: > > Hello All, > > It appears to me that we are conflating a number of issues, and > complicating the matter with a software issue. > > > > First off, the conversion between raw and corrected calorimeter > cell energy involves a sampling fraction. For a traditional sampling > calorimeter (composed of a sandwich of insensitive absorber and sensitive > readout) this is considered an intrinsic characteristic of each cell. It is > the best estimate, based only on the energy recorded in the sensitive > component, of the energy deposited in that cell. This is a cell correction > factor and is essentially fixed. For a total absorption calorimeter such as > ours this should be 1. (Pedestals and gains are considered part of the > electronic readout correction.) > > > > Secondly, after clustering, the energy measurement is refined based on > cluster properties (e.g. shower shape, position, distance from edges, etc.) > or other input (e.g. associated track). These are cluster corrections and > are dynamic. For HPS Holly's note describes these quite nicely. > > > > The confusion arises from a combination of software implementation and > semantics. We, of course, want to be able to compare the "raw" and > corrected cluster energies. In this context "raw cluster energy" is > synonymous with the sum of the constituent crystal energies. The corrected > energy includes cluster-specific effects including energy lost between the > crystals (tranverse as opposed to longitudinal sampling, if you will). > Unfortunately, the method in BaseCluster, getRawEnergy(), was written to > return the sum of sampled energy in the constituent cells without a > sampling fraction applied. I have no idea why this method was ever > introduced, and as near as I can tell, it was never used. > > > > Here is my proposal: > > 1.) We maintain our sampling fractions at 1.0 > > > 2.) We change the call to getRawEnergy() in > HPSEcalClusterIC.recalculateForParticleID() > to getEnergy(). > > 3.) We then eliminate the references to raw energy in > org.lcsim.event.BaseCluster. > > 4.) We add a method getUncorrectedEnergy() which simply returns the sum of > the constituent cells (crystals). > > I believe this satisfies the desire to have both the "raw" and corrected > cluster energy while also removing the artificial impediment of not being > able to use a CalorimeterHit read back from LCIO (SIOCalorimeterHit). > > If this is not clear I can make a presentation at our software meeting on > Thursday to explain in more detail and answer any outstanding questions. > > > > Norman > > ------------------------------ > *From:* [log in to unmask] <[log in to unmask]> > on behalf of Stepan Stepanyan <[log in to unmask]> > *Sent:* Tuesday, December 16, 2014 3:37 AM > *To:* McCormick, Jeremy I.; Uemura, Sho > > *Cc:* hps-software > *Subject:* Re: EVIO to LCIO: Raw Hit Energy > > Jeremy and Sho, > > Sorry if my comments are not on the same "correction". > > The referred sampling fraction, 0.89, I assume is the correction you need > to get electron/photon energy from reconstructed raw energy of the cluster. > If that the case, then it is in reality energy and angle dependent, not > just a > simple number. Holly's code takes care all of that dependence, and as I > rote yesterday it is important to have both raw and corrected energy at the > end, it helps to understand calorimeter and reconstruction better since > the sampling fractions are extracted from simulations and there are details > that can be iron out looking data as well. > > Holly has a nice note in HPS-NOTE arxive you can take look: > > https://misportal.jlab.org/mis/physics/hps_notes/viewFile.cfm/2014-001.pdf?documentId=1 > > Stepan > On 12/16/14, 1:04 AM, McCormick, Jeremy I. wrote: > > Yes, I think you’re right on both points, Sho…. > > Is there some reason we’re not including the actual sampling fraction in > the framework? Does it cause other problems/inconsistencies to set it to > something other than 1.0 in the sampling fraction properties file? > > Looking at BaseCalorimeterHit in LCSim (which I wrote long ago in a > galaxy far far away), I do think it could be improved to help us solve this > problem. Only correctedEnergy is ever persisted to the LCIO file for > CalorimeterHit, in which case, when reading these hits back in, the raw > energy will never get set. So it doesn’t really help that much to set this > in recon. It will never get persisted. > > I think we can fix this by applying the sampling fraction in reverse in > the getRawEnergy method of BaseCalorimeterHit if it isn’t set, but that > sampling fraction needs to actually be correct for this to work, unless > we’re happy with raw and corrected energy being the same (due to the 1.0 > value). > > We can also add more methods too if that’s helpful. If we need to > override the default SamplingManager implementation and make something else > available to put in 0.89 across the board so it doesn’t need to go into > every detector description’s properties, we can do that too. We can also > add set methods for raw energy etc.. > > But it seems like it would be best if the right raw energy was returned > automatically by including the correct sampling fraction into LCSim in the > first place so the reverse calculation gives an answer that makes sense. > > Does this all make sense? Or am I missing some technical details about > HPS Java and our clustering algorithms that would prevent us from doing it > in this way? > > On Dec 15, 2014, at 9:47 PM, Sho Uemura <[log in to unmask]> wrote: > > Two things. > > 1. The sampling fraction in LCSim is set to 1, so "raw energy" and > "corrected energy" are always the same for our hits. This is regardless of > the fact that the sampling fraction of the physical detector is 0.89; > unless that number gets plugged in to the LCSim sampling fraction > calculator, it has no bearing on this discussion. > > 2. Yes, it is trivial to calculate raw energy from corrected energy, > particularly given point 1. But this is not done automatically; > BaseCalorimeterHit.getRawEnergy() crashes if the raw energy is unset. > (Corrected energy is, on the other hand, automatically calculated. I think > you could argue that this is the way it should be, but I don't really > know.) So you could catch the exception and do the calculation yourself, > but that's really a shitty hack. > > On Tue, 16 Dec 2014, McCormick, Jeremy I. wrote: > > Hi, > > Perhaps I?m not completely understanding all the details here in this > thread, but isn?t the raw energy easily recoverable if you have the > corrected energy and know the sampling fraction that was applied to get it? > > correctedEnergy = rawEnergy / samplingFraction > > where sampling Fraction is the 0.89 number (from Holly?s email). > > So can?t you just get the raw energy back with?. > > rawEnergy = correctedEnergy * samplingFraction > > It seems like if you have one you can get the other. > > If there are spots in BaseCluster that use raw energy and this is actually > needed then it seems like this calculation could be performed. > > I had thought there was behavior in BaseCalorimeterHit to do this > (calculate raw from correct energy) so that the code would not crash, but I > need to look over it again? > > Can someone send the exact error that is happening which is causing > problems here? (Kyle?) > > ?Jeremy > > On Dec 15, 2014, at 2:50 PM, Greg Kalicy <[log in to unmask]< > mailto:[log in to unmask] <[log in to unmask]>>> wrote: > > Hi, > > Why can not we change the labelling until corrections work again? It will > be very confusing probably even for us after 2 weeks - which were corrected > and which not? > > Cheers, > > Greg > > On 15 Dec 2014, at 17:44, Holly Vance <[log in to unmask]< > mailto:[log in to unmask] <[log in to unmask]>>> wrote: > > Hi, > > I think the simplest fix in the clustering is to set the raw energy and > the corrected energy to be the same until the energy corrections are > done-at which point, we can overwrite the corrected energy. This should > work with all of the previous codes of others (since raw energy is not > filled by anything else) and allow us to store the information from both in > the offline clustering. > > The only part I don't like about this is the labeling. If something says > "corrected energy" then I feel it should really be the corrected > energy-otherwise it can get confusing. Currently, the corrected energy is > uncorrected since the event display is reading this. Not a big deal as long > as everyone knows when the corrections occur in the code. > > On Mon, Dec 15, 2014 at 5:35 PM, Graf, Norman A. <[log in to unmask]< > mailto:[log in to unmask] <[log in to unmask]>>> wrote: > > Hello Stepan, > > Agreed. > > Norman > > ________________________________ > From: Stepan Stepanyan <[log in to unmask]<mailto:[log in to unmask] > <[log in to unmask]>>> > Sent: Monday, December 15, 2014 2:26 PM > To: Graf, Norman A.; 'Holly Vance' > > Cc: Uemura, Sho; Kyle McCarty; hps-software > Subject: Re: EVIO to LCIO: Raw Hit Energy > > Norman and Holly, > > I may not fully understand problem but want to point > that we need to keep both reconstructed cluster energy > and corrected final energy of particle. This is how our > clustering worked and it was absolutely useful. > > Thanks, Stepan > > On 12/15/14, 4:37 PM, Graf, Norman A. wrote: > Hello Holly, > Thanks for that follow-up. It?s clear we should discuss this some more. > Norman > > From: [log in to unmask]<mailto:[log in to unmask] > <[log in to unmask]>> [mailto:[log in to unmask] > <[log in to unmask]>] On Behalf Of Holly Vance > Sent: Monday, December 15, 2014 1:27 PM > To: Graf, Norman A. > Cc: Uemura, Sho; Kyle McCarty; hps-software > Subject: Re: EVIO to LCIO: Raw Hit Energy > > Hi Norman, > > I can fix change this in the offline clustering code. I would like to > remind you that sampling fractions are actually on the order of about 0.89 > until corrected. I strongly feel that we need to preserve both of these > energies because I would like to compare what we really find with how I > calculated the energy corrections in simulation. Using the setEnergy() > method later in reconstruction will overwrite the original energy. > > At the moment, I've removed energy corrections from the clustering since > it's necessary that getEnergy() returns the raw (uncorrected) energy for > use in the event display in the counting house. All corrections will be > done later in reconstruction with cluster track matching, but I don't think > it's good to overwrite the raw/uncorrected energy yet. > > > > On Mon, Dec 15, 2014 at 4:13 PM, Graf, Norman A. <[log in to unmask]< > mailto:[log in to unmask] <[log in to unmask]>>> wrote: > Hello Holly et al., > Here?s my proposal: > We change the call to getRawEnergy() in > HPSEcalClusterIC.recalculateForParticleID() > to getEnergy(). Our sampling fractions are 1.0 so the returned energy is > the same in either > case. This method is not called at present, so it does not change any > behavior. > We then eliminate the references to raw energy in > org.lcsim.event.baseBaseCluster. > I can do this now, or we can discuss this further in detail. > Norman > > From: Holly Vance [mailto:[log in to unmask] <[log in to unmask]>< > mailto:[log in to unmask] <[log in to unmask]>>] > Sent: Monday, December 15, 2014 1:06 PM > To: Graf, Norman A. > Cc: Uemura, Sho; Kyle McCarty; hps-software > > Subject: Re: EVIO to LCIO: Raw Hit Energy > > Hi all, > > The raw energy is calculated separately and then set because it includes > considerations for hits shared between clusters (energy is distributed > then). Also, the raw energy is used separately to calculate the corrected > energy. > > It is a bit of a question of semantics, but there must be a distinction > for the offline clustering since this is where the corrections happen. > > Let me know how we wish to proceed. > > On Mon, Dec 15, 2014 at 3:10 PM, Graf, Norman A. <[log in to unmask]< > mailto:[log in to unmask] <[log in to unmask]>>> wrote: > Hello All, > This is complicated by the fact that HPSEcalClusterIC actually calls > getRawEnergy() before > calculating the cluster position and energy corrections. I am checking to > understand > whether this is just a semantic issue. > Norman > > -----Original Message----- > From: [log in to unmask]<mailto:[log in to unmask] > <[log in to unmask]>> [mailto:[log in to unmask] > <[log in to unmask]><mailto:[log in to unmask] > <[log in to unmask]>>] On Behalf Of Sho Uemura > Sent: Monday, December 15, 2014 10:54 AM > To: Kyle McCarty > Cc: hps-software > Subject: Re: EVIO to LCIO: Raw Hit Energy > > This is a known incompatibility between the LCSim builtin classes - a > CalorimeterHit read from LCIO (SIOCalorimeterHit) has a corrected energy > but no raw energy, and the LCSim base implementation of Cluster > (BaseCluster) uses the hit raw energy. We've always tried to avoid this by > using corrected energy when possible. > > The HPS subclasses of BaseCluster do not override that behavior; it's not > "our fault" that the cluster code crashes. But either BaseCluster gets > changed so it doesn't use raw energy, or we override the methods of > BaseCluster that do. > > On Mon, 15 Dec 2014, Kyle McCarty wrote: > > Hello hps-software, > > I am trying to write a version of the GTP clustering algorithm to run > over EVIO readout data and form clusters from the hits. This is useful > both to get cluster data that closely matches what the hardware is > actually seeing and also for trigger verification and diagnostic > drivers, since these will need to run the trigger over clusters that match > the hardware. > > I am running into a problem with this because the readout hits do not > declare a raw energy and attempting to access it causes a RuntimeException. > Normally, we use corrected energy, which is available, but the addHit > method in HPSEcalCluster apparently calls getRawEnergy at some point > and thusly crashes the simulation. > > Is there a way to fix this so that the hits in the EVIO readout will > have this value when converted to LCIO? Alternatively, should we > change the HPSEcalCluster to use the corrected energy? > > Thanks, > > Kyle > > ###################################################################### > ## > 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 > > > -- > BEGIN-ANTISPAM-VOTING-LINKS > ------------------------------------------------------ > > NOTE: This message was trained as non-spam. If this is wrong, > please correct the training as soon as possible. > Teach CanIt if this mail (ID 01NrUbF6w) is spam: > Spam: about:blank > > Not spam: about:blank > > Forget vote: about:blank > ------------------------------------------------------ > END-ANTISPAM-VOTING-LINKS > ________________________________ > > Spam > Not spam > Forget previous vote > > ________________________________ > > 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 > > ________________________________ > NOTE: This message was trained as non-spam. If this is wrong, please > correct the training as soon as possible. > Spam<> > Not spam<> > Forget previous vote<> > > ________________________________ > > 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 > > > > ------------------------------ > > 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 > ------------------------------ > NOTE: This message was trained as non-spam. If this is wrong, please > correct the training as soon as possible. > Spam > <https://www.spamtrap.odu.edu/canit/b.php?i=01Nsfoxdv&m=0d503e2fa53d&t=20141216&c=s> > Not spam > <https://www.spamtrap.odu.edu/canit/b.php?i=01Nsfoxdv&m=0d503e2fa53d&t=20141216&c=n> > Forget previous vote > <https://www.spamtrap.odu.edu/canit/b.php?i=01Nsfoxdv&m=0d503e2fa53d&t=20141216&c=f> > > ------------------------------ > > 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