[Halld-offline] Save Detector Elements in REST?

[Paul Mattione]

Well, if, for example, the timing in a TOF paddle was mis-calibrated, rather than having an acceptance hole, you may not want to cut on the timing from that paddle at all when you do your analysis.  But you’d need to have the paddles saved to do that.  

Perhaps this doesn’t work for the calorimeters though.  

 - Paul

On May 25, 2016, at 9:47 PM, Shepherd, Matthew <mashephe at indiana.edu> wrote:

> 
> Paul,
> 
> I'd argue that if we find out a detector element is inefficient or miscalibrated, we modify our MC to simulate this effect and then it will be accounted for in our efficiency determination.  Some fiducial cuts will need to be made, but I don't think that will require module information.  Saving only the module information for the block with the most energy in a shower doesn't seem to be too useful.  
> 
> Matt
> 
> ---------------------------------------------------------------------
> Matthew Shepherd, Associate Professor
> Department of Physics, Indiana University, Swain West 265
> 727 East Third Street, Bloomington, IN 47405
> 
> Office Phone:  +1 812 856 5808
> 
>> On May 25, 2016, at 5:50 PM, Paul Mattione <pmatt at jlab.org> wrote:
>> 
>> Should we save the detector elements in REST?  In other words, the:
>> 
>> BCAL module, FCAL column/row, SC paddle, TOF paddles, TAGM counters, TAGH columns
>> 
>> We haven’t been so far, but I think they could be useful.  For example, if we determine later that a detector element is inefficient, or miscalibrated, we may need to cut all data from that particular detector element from our analyses.  It would cost an extra couple bytes per object.  Thoughts?  
>> 
>> - Paul
>> 
>> 
>> _______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>