Page History

...

(rev. 16 Feb 2010, Pass 8 discussion Grove, Bruel, Baldini, Usher)

...

On 5 Aug 2010 (Day 217), at 5:24 PM EDT, J. Eric Grove wrote:

Wiki MarkupChul,
Here I've detailed the actions for FixXtalResp in the cases we currently understand. I've added a new CalXtalRecData status word definition \ [at the bottom of this email\] adding Bill's corrected-energy bit and a bit to indicate that we've mitigated the failure.
Eric

case == bad plus-face HEX8 && bad plus-face HEX1 && ! plus-face HE autoranging disabled
/* this is the case for the current failure and current configuration */
/* if one of the HEX ranges is best range, fix it */
/* if plus-face first range == (HEX8 || HEX1),
	calculate E using the opposite face and the externally provided longitudinal position
	clear the bad energy bit
	set the externally provided longitudinal position bit
	set the failure-mitigation energy bit
*/


case == bad plus-face HEX8 && bad plus-face HEX1 && plus-face HE autoranging disabled
/* this is the case for the current failure, but it requires a configuration we have not used */
/* if LEX1 is best range and saturated, fix it */
/* if plus-face first range == LEX1 && plus-face > 4050 (i.e. saturated),
	calculate E using the opposite face and the externally provided longitudinal position
	clear the bad energy bit
	set the externally provided longitudinal position bit
	set the failure-mitigation energy bit
*/


case == bad plus-face LEX8 && bad plus-face LEX1 && bad plus-face HEX8 && bad plus-face HEX1
/* this is the case we may get to soon if this GCFE continues to degrade and the LE ranges fail */
/* in all cases,
	calculate E using the opposite face and the externally provided longitudinal position
	clear the bad energy bit
	set the externally provided longitudinal position bit
	set the failure-mitigation energy bit
*/

...

1. Perform the start xtal rec step.
   • We'll put in all the new bits to keep track of what's happening, according to the scheme outlined above. Chul and Tracy will follow up on this and get it done.
2. If there's one or more saturated xtal(s), the first thing we'll do in CalRecon is a fit using the transverse information only with the full xtal collection (i.e. before the clustering) to be used to fix the position for saturated xtals. Luca B. and Philippe will take care of this.
   • This will require moving the current fitting routine (now living in CalRecon/src/Clustering/MomentsClusterInfo.cxx) in some common area (Tracy suggests CalRecon/src/Utilities/) to be used in more than one place. Luca B. will take care of this.
   • As a side project, the possibility of not using Minuit for the fit will be investigated, in order to gain in speed and avoid a dependency on ROOT. This is low-priority project that Luca B. will take a look into.
3. At this point (if there are saturated xtals) from CalRecon we will call a dedicated tool in XtalRecData CalXtalResponse to set the longitudinal position to our best value, based on the transverse fit (will need some coordination between all of us).
   • After this point the xtalRecData CalXtalRecData objects in the TDS will have a reasonable longitudinal position information even for the saturated xtals, and the correct information will propagate trasparently to the downstream code (with the proper status bit set).
4. The next step is the calorimeter clustering (i.e. the splitting of the xtal collection in clusters).
5. And after that we'll go through the standard transverse fit/moments analysis/classification on a cluster by cluster basis.
   • We decided to keep the CalMomentsData as the basic object the CAL moments analysis acts on. Luca B. will take care of propagating all the new information (i.e. the status bits) to the object.
   • Further possible adjustments to the xtals that need transverse fit at the cluster level will be done by calling the proper tool at this point.