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