 |
 |
Hi, There was a long discussion on the list a few days ago about raw vs corrected energy for calorimeter hits.... When both raw amd corrected values are present and set to non-zero values, they are likely going to be equal. Because we use a 1.0 sampling fraction. So that means the sampling fraction algorithm always returns raw and corrected energies that are equal, because it divides the energy by the sampling fraction. The reverse calculation for corrected to raw would also return 1. For LCIO CalorimeterHit objects, one should not count on the raw energy being set, because this information is not persisted to the LCIO file. There is the possibility of setting a raw and corrected energy through the BaseCalorimeterHit constructor within an LCSim job, but if these values are different, the raw energy information is lost when the LCIO is written and the job ends. So when reading these types of hits back within an analysis job from LCIO, the getRawEnergy() call will always return 0. The corrected energy IS persisted for CalorimeterHit objects, so this can be read back in your job just fine. That's why, in general, getRawEnergy() should not be used on these objects. For SimCalorimeterHit, the getRawEnergy() method will return the correct value, and it is persisted to the LCIO. The getCorrectedEnergy() method will also work, because the corrected energy is set automatically through the sampling fraction algorithm. Since in our case, these two values will be identical, the getCorrectedEnergy() method should also be used for SimCalorimeterHit for the best portability. That said, getRawEnergy() will also have a sensible value for those types of hits. So the general conclusion here is that one should prefer to use, in nearly all cases, the getCorrectedEnergy() method when working with ECAL hits. If there are calls to CalorimeterHit.getRawEnergy() in clustering code etc. they should be removed in favor of using the getCorrectedEnergy() method instead. Also, I have changed these classes recently so that errors are not going to be thrown if you call CalorimeterHit.getRawEnergy() without it having been explicitly set. The method will is simply going to return a 0 value in lieu of throwing an Exception. I think this is reasonable, and I don't think it should be a fatal exception to call this method. This above is independent of cluster energy corrections, which basically have nothing to do with the technicalities of the raw vs corrected energy. The corrections are applied to clusters, not their hits, and so if we want to be able to easily see uncorrected vs corrected cluster energies, then probably the best way to do this is writing two different cluster collections, one "uncorrected" collection which has pre-corrected energies, and another "corrected" collection, after the algorithm has been applied. One could also setup an LCRelation to associate the uncorrected and corrected collections, or recover this link in some other way like looking at the list of hits to see which clusters match up with each other. This should be discussed I think, but bear in mind the way that the hit energies work is independent of this, because the corrected clusters have their energy set explicitly. By default, an uncorrected cluster's energy would be equal to the sum of all its hit energies. Is this all more clear now? --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