Skip to content
Snippets Groups Projects
user avatar
Stephen A. Wood authored
   {prefix}dc_fix_lr
        Historically, in the ENGINE, if a hit is used in multiple
        space points/stubs, the left/right assignment for that hit, which
        is later used in track fitting, is that assigned for the last stub
        encountered with that hit.  Properly, the left right assignment
        should be allowed to be different in different space points.  If
        this parameter is set to zero (e.g. in hcana.param), then the
        ENGINE behavior is used.  For new analyses, it should be set to one.
        (Which is the default)
   {prefix}dc_fix_propcorr
        When a hit gets put into a stub, the distance of the hit from the
        discriminator can then be estimated.  In the engine, a correction to
        the drift time (and thus drift distance) is applied.  However, if
        that hit ends up in another stub, the correction will get applied again,
        resulting in a over correction.  Setting this flag to 1 will give that
        hit a different corection for each stub that it is in.

These flags will default to the new "correct" way of handling hits if
the above parameters are not set in a parameter file.  Currently, both
flags are set to zero in hcana.param to replicate the ENGINE behavior.

To implement these changes, the propagation correction and L/R information
for each hit is saved in space point and track classes.  This information
is still saved in the hit class, but only used if in ENGINE compatibility
mode.

The THcDCTrack class now saves a list of space point pointers instead
of space point indices.

The AddSpacePoint method now also copies all the hit information into
the track object so that THcDC doesn't need to explicitely copy all
the hits.

The FindStub method, which fits a stub track to a space point is passed
the space point rather than a list of hits
6a33dcf3
History

hcana - Hall C ROOT/C++ analyzer

hcana is an under-development tool to analyze data from the HMS, SHMS and SOS spectrometers in Hall C at JLab. It is being developed to replace the historical Hall C analyzer, ENGINE, which was written in Fortran. hcana will be the package used to analyze Hall C date in the 12 GeV era. hcana is being written in C++, using the CERN ROOT framework. hcana is an extension to the Hall A analyzer, PODD.

NOTE: In the process of retrieving the hcana source code, a copy of the Hall A PODD package will be downloaded. The version of PODD included has been slightly modified for use with hcana. For an official version of PODD, see the ROOT/C++ Analyzer for Hall A page.

Downloading

Instructions for downloading hcana can be found in the Hall C Wiki.

Compiling

hcana may be compiled with either make or scons. Switching between these two build systems make require some cleanup of dependency files, binary files and other autogenerated files.

Before compiling, type source setup.sh or source setup.csh depending on whether your shell is bash or csh.

Compiling with make

make

Compiling with scons

python ./podd/scons/scons.py

To do the equivalent of "make clean", do python ./podd/scons/scons.py -c To compile the standalone codes the are part of podd, do python ./podd/scons/scons.py standalone=1

Running

Basic instructions on how to run hcana are in the Hall C Wiki.

Contributing

To participate in hcana code development, contact Mark Jones or Stephen Wood.