[Halld-offline] Save Detector Elements in REST?

[Mark Ito]

I agree. The gain from saving the module info is speculative at this point.

On 05/26/2016 07:23 AM, Curtis A. Meyer wrote:
> Unless we have a reallly good reason (that I don’t see), we should 
> avoid a large increase to
> the REST footprint. Our goal has been for that to be compact an 
> movable. Let’s not bloat
> it.
>
> Curtis
> ---------
> Curtis A. MeyerMCS Associate Dean for Faculty and Graduate Affairs
> Wean:    (412) 268-2745Professor of Physics
> Doherty: (412) 268-3090Carnegie Mellon University
> Fax:         (412) 681-0648Pittsburgh, PA 15213
> curtis.meyer at cmu.edu 
> <mailto:curtis.meyer at cmu.edu>http://www.curtismeyer.com/
>
>
>
>> On May 25, 2016, at 9:52 PM, Paul Mattione <pmatt at jlab.org 
>> <mailto:pmatt at jlab.org>> wrote:
>>
>> 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 
>> <mailto: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 
>>>> <mailto: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 <mailto:Halld-offline at jlab.org>
>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>>
>>
>>
>> _______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org <mailto:Halld-offline at jlab.org>
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline

-- 
marki at jlab.org, (757)269-5295

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160526/5f69749c/attachment-0002.html>