[Halld-offline] Save Detector Elements in REST?

[Richard Jones]

Hello Paul,

This might be a good idea, particularly if further shower corrections or
fiducial cuts can make use of counter indices. If you decide to go this
way, I would strongly recommend adding the extra information NOT as
additional attributes in existing tags (that breaks hddm compatibility with
old/new files using the same executable) but by adding a sub-tag under the
existing tag. This is especially useful for one-to-many maps such as
fcalShower -> fcalHit. An example of how to do this might be:

old form:

<fcalShower minOccurs="0" maxOccurs="unbounded" jtag="string"
                x="float" y="float" z="float" t="float" E="float"
                xerr="float" yerr="float" zerr="float" terr="float" Eerr="float"
                xycorr="float" xzcorr="float" yzcorr="float"
                tzcorr="float" Ezcorr="float"
                lunit="cm" tunit="ns" Eunit="GeV"/>

proposed new form:

<fcalShower minOccurs="0" maxOccurs="unbounded" jtag="string"
                x="float" y="float" z="float" t="float" E="float"
                xerr="float" yerr="float" zerr="float" terr="float" Eerr="float"
                xycorr="float" xzcorr="float" yzcorr="float"
                tzcorr="float" Ezcorr="float"
                lunit="cm" tunit="ns" Eunit="GeV">

    <fcalHit minOccurs="0" maxOccurs="unbounded" row="int"
column="int" Eblock="float" tblock="float" />

</fcalShower>

One warning to keep in mind about this, this will increase the size of the
rest event substantially.
-Richard Jones


On Wed, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160525/99e49042/attachment-0002.html>