 |
 |
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
Norman
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]>> 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]>> 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]>> wrote:
Hello Stepan,
Agreed.
Norman
________________________________
From: Stepan Stepanyan <[log in to unmask]<mailto:[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]> [mailto:[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]>> 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]<mailto:[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]>> 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]> [mailto:[log in to unmask]<mailto:[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<https://www.spamtrap.odu.edu/canit/b.php?i=03NrWzOm6&m=257cb4a0adbc&t=20141215&c=s>
Not spam<https://www.spamtrap.odu.edu/canit/b.php?i=03NrWzOm6&m=257cb4a0adbc&t=20141215&c=n>
Forget previous vote<https://www.spamtrap.odu.edu/canit/b.php?i=03NrWzOm6&m=257cb4a0adbc&t=20141215&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
________________________________
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