[Halld-offline] hits missing after pass thru evio encoding/decoding

[Richard Jones]

Hello Sean,

Thank you for your reply. I have set up a web folder with a bunch file
files in it to demonstrate the problem.

http://zeus.phys.uconn.edu/halld/tagger/
fp-microscope/sim-recon-rj-pm/work/dev

In particular:

   - dana_events_1.hddm - 100 bggen events before conversion to evio
   - rawevent_1.evio - same 100 bggen events after conversion to evio

The same pair with _0 instead of _1 are created using our working branch.
Both show the same features described in my previous message. You can run
hd_dump on the above files (see run_danadump.sh in the above web folder) to
see the multiplicities of various objects from each of the types of inputs.
For a quick look, I have created output files for all 100 events from
hd_dump and stored them in the same folder for you to browse.

   - pre.log.1...100 - hd_dump output for events 1 - 100 from
   dana_events_0.hddm
   - post.log.1...100 - hd-dump output for events 1 - 100 from
   rawevent_0.hddm
   - tre.log.1...100 - hd_dump output for events 1 - 100 from
   dana_events_1.hddm
   - tost.log.1...100 - hd_dump output for events 1 - 100 from
   rawevent_1.hddm

-Richard J.

-Richard Jones


On Wed, Aug 27, 2014 at 12:56 PM, Sean Dobbs <s-dobbs at northwestern.edu>
wrote:

> Hi Richard,
>
> To answer your last question first, I've been checking the consistency of
> this process, so I can answer at least some of your questions.
>
> - The loss in FDC hits (which presumably causes the tracking problems you
> see) is due to a known problem in the translation table for the FDC wires.
>  A fix is on the way.
>
> - I haven't seen the problems in BCAL showers that you're reporting (and I
> just checked Monday!).  If you can provide some sample files, I can take a
> look at this for you.
>
> ---Sean
>
>
> On Wed, Aug 27, 2014 at 11:45 AM, Richard Jones <richard.t.jones at uconn.edu
> > wrote:
>
>>  Hello all,
>>
>>  I am working on validating the sim-recon-rj-pm branch before we check
>> it into the trunk, and one of the things I am doing is making sure that the
>> tagger hits that are now being decoded from the evio fADC/TDC structs are
>> properly showing up as dana objects in the analysis. To do this, I am
>> running simulation output files through the hddm -> evio converter and then
>> reading the events back into dana from evio input files. The problem is
>> that I am seeing lots of missing hits that get dropped during this
>> coding/decoding process, and I wonder if this is correct. BTW, I also see
>> it for trunk code, although the output from hdgeant is different between
>> the two branches so I cannot do event-by-event comparisons.  Here is what I
>> see:
>>
>>    - BCAL - same number of hits (DBCALHit objects), but major decrease
>>    in the number of clusters (DBCALShower, DBCALCluster) that are made out of
>>    them. Is something being incorrectly transmitted through the filter?
>>    - FCAL - things all look consistent here
>>    - CDC - same number of hits before and after
>>    - FDC - 10% loss of hits (DFDCHit objects) , but major decrease in
>>    higher level objects like DFDCPseudo, DFDCIntersection which have 90% loss.
>>    - StartCounter - same number of hits before and after
>>    - FTOF - some hits are missing, but the higher-level objects
>>    (DTOFPaddleHit, DTOFPoint) seem consistent, maybe just a threshold cut?
>>    - Track objects - there may be a correlation between the pre-filter
>>    and post-filter statistics on these objects, but it is not obvious. The
>>    counts are rarely consistent between them for any of the track objects.
>>    - Neutrals objects - ditto.
>>
>> Is there someone who is taking the lead in studying the behavior of this
>> filter? Should I ignore these differences, and consider the to/from evio
>> capability of our offline to be unready for actual use?
>>
>>  -Richard J.
>>
>
>
>
> --
> Sean Dobbs
> Department of Physics & Astronomy
> Northwestern University
> phone: 847-467-2826
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20140827/d6299aac/attachment-0002.html>