Print

Print


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]> 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]> 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]> wrote:

Hello Stepan,

 Agreed.

Norman



From: Stepan Stepanyan <[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]] 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]> 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]]
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]> 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]] 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

 

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