[Shms_users] Hall C 12 GeV software update (mailing list & request for additional info)

[Brad Sawatzky]

This is Ole Hansen's response.  It got bounced from the mailing list for
some reason (we'll get that fixed ASAP).


---------------------
On Mon, 22 Aug 2011, Ole Hansen wrote:
---------------------

Hi folks,

a few quick comments below.

On 8/22/2011 17:30, Brad Sawatzky wrote:

     -------- Notes/Suggested Outline for Future Progress --------



      C++ Analyzer:
      - Adapt Hall A raw-decode stage to parse Hall C CODA files.  (DAQ
        folks should know what I mean here.)
        - I had the impression that this may already be complete?  If so, a
          link to the code would be great!


I am curious about the differences between Hall A and Hall C CODA files. I would think that the Hall A CODA decoder should at least be able to run through a Hall C data stream, even if it doesn't actually decode module data. The CODA format (event headers, offset pointers, etc.) is well documented, and we are not doing anything non-standard in Hall A.

Whatever differences we discover would be a good starting point for generalizing the decoder logic. There is admittedly quite a bit of hardcoded stuff in there.

Of course, we have most probably not implemented all the Hall C hardware, which will cause certain decoder error messages. That brings me to the weakest point of the decoder: processing of different hardware modules (mostly VME) is coded in the bad old Fortran way - one long string of if-elseifs. This should be completely rewritten in an object-oriented way. Once that is in place, code for new electronics can be loaded dynamically from user-written shared libraries at run time, as we already do with detectors etc.


        - NOTE:  The 'database' backend in the Hall A analyzer has be
            long-recognized as a big weakness.  Multiple hacks have been
            implemented to address this -- none are very satisfying.  A
            proper solution would greatly benefit both Halls.  This would be
            a clean, well-defined project for a good student to take on.


True. One staff member and one postdoc worked on a "real" database solution at different points in time, and neither attempt was successful (i.e. I never saw a line of code checked in). But before someone merrily hacks away, please let's design it first.


        - compare track reconstruction event-by-event
          - It would be disconcerting if there are significant differences
            between what the "Hall A" tracking algorithms generate and what
            the FORTRAN analyzer ends up with.  I would like to think there
            is minimal special case "magic" in either tracking codes.



Keep in mind that the tracking algorithm for the Hall A HRS has been specifically written for our set of VDCs. I don't think you have VDC reconstruction in your Fortran analyzer, or do you? Even if you do, I do think there may very well be "special case magic". I doubt such a comparison would work out of the box. But yes, we did the same thing, we compared Fortran and C++ tracking output in exhaustive detail - after we wrote the C++ tracking code from scratch.

Gabi and I talked at PANIC about having a meeting at JLab sometime in August/September. We should make it a plan. Hopefully, we can use the new old mailing list for further discussions. (I guess I'm waiting for moderator approval.)

Cheers,
Ole