Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address the numerous general FIXMEs in THaDecData #11

Closed
hansenjo opened this issue Oct 3, 2013 · 1 comment
Closed

Address the numerous general FIXMEs in THaDecData #11

hansenjo opened this issue Oct 3, 2013 · 1 comment
Assignees
Milestone

Comments

@hansenjo
Copy link
Member

hansenjo commented Oct 3, 2013

THaDecData is consistently a performance hog, largely for the reasons implied in the FIXMEs. The entire class should probably be rewritten with (a) configurability and (b) performance in mind.

@ghost ghost assigned hansenjo Oct 23, 2013
hansenjo referenced this issue Nov 6, 2013
Implemented a new BdataLoc class hierarchy that handles (decodes) raw
event data from single front end channels and related information.
Supports either crate/slot/channel addressing (including multihit
channels) or crate/header/offset addressing (data identified by header
words in the event buffer). Also supports a new data type Roclen that
reports the event length in a given crate and a new TrigBitLoc class
to handle Hall A-style trigger bits. This last one should eventually
go into the Hall A library. See the top of BdataLoc.C for the full
list of definitions (calls to BdataLoc::DoRegister).

This is pretty much what I had in mind in July 2007 when I wrote the
FIXME comments in the original.

The VDC efficiency calculation has been moved into a separate VDCeff
physics module that will be checked in later.

The database may either be in the legacy format that was understood by
the original code or, preferably, in a new key/value format. For the
latter, one needs database keys like

D.crate = \
  syncadc1, 1, 25, 16,  \
  syncadc2, 2, 24, 48,  \
...

where "crate" corresponds to the BdataLoc type one wants to define for
the given variable names. There is exactly one key per BdataLoc type
(NOT per variable!). The key's value is one long string (continued
with \ continuation marks if necessary) containing n-tuples of
configuration parameters, name first. Spaces, commas and tabs are
accepted as delimiters in the database values. Most BdataLocs need
4-tuples as in the example above), however trigger bit variables take
6-tuples:

D.bit = bit1  3  5  64  0  1500

where the values indicate crate, slot, channel, cutlo and cuthi. The
latter two values are the lower and upper limits of the TDC cut to
apply to identify a set bit. (Ask Bob for details on how this hardware
is set up.)

Support for the legacy file format can be enabled by defining of
DECDATA_LEGACY_DB.  This is currently the default. In that case,
database files are only assumed to be in new format if they have a
first line comment containing "Version: 2".

The class no longer defines any histograms. Most of the histos in the
original were for the VDC efficiency calculation anyway. If you need
to histogram roclen12 or roclen16, for example, define roclen
variables here and histograms of these variables as output
definitions.

Use Print("FULL") after Init() to see all defined variables, including
channel definitions.

An example key/value type database file is provided in DB/20121201/db_D.dat
@hansenjo
Copy link
Member Author

hansenjo commented Nov 6, 2013

Closed by 36ca93d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant