[Halld-online] Generating translation table from JInventory database

[David Abbott]

  Just FYI,
     I have been lobbying for all JLAB-based modules to use the same Block header/trailer
format for VME readout. This format has (in the Block header) for each module the slot number
and the module type. 
     In addition there is a mechanism for each module to optionally pass (for each event)
the event number (22 bits) , time stamp (either 24 or 48 bits), and any user programmed
parameters like look-back or peak window integral sizes (total of 32 bits).
    Finally, there is a mode in the Event builder to include both a run number and a run 
type id for every event (or event block).

   Perhaps this is helpful in avoiding possible database inconsistancies...

     David



----- Original Message -----
From: "David Lawrence" <davidl at jlab.org>
To: halld-online at jlab.org
Sent: Thursday, September 6, 2012 8:44:20 AM
Subject: Re: [Halld-online] Generating translation table from JInventory	database


Hi Elliott et al.,

     Here are my thoughts:

   I mentioned briefly at the meeting yesterday that there are really 2
stages to parsing the raw data files into a form that has "detector
indexes" such as package/plane/wire.

1.) Parse the data from the module based on it's type (f250ADC,
     f125ADC, F1TDC, ...)

2.) Translate the rocid/slot/channel into the detector index.


   Stage 1 produces objects like Df250PulseIntegral and DF1TDCHit.

   Stage 2 produces objects like DBCALHit and DTOFHitRaw (using the
objects from stage 1 as input along with the translation table).

   I would propose that we formulate a standard for the DAQ system to
write out the information on the module type with the EVIO bank. For
instance, we could reserve certain "num" values to correspond to the
module types. This would be easy for the DAQ system since it knows
what type of module produced the data. This would allow stage 1 to
be completed without access to a database.

   The alternative would be to store the slot number so that the database
would then be accessed to get the module type. Note that the slot number is
buried in the module data, but cannot be accessed from there until the
module type is known. We'd therefore have to encode the slot number
in the bank header which is no easier than just encoding the module type.

Storing the module type in the EVIO bank eliminates the problem of
the database needing to be up to date for stage 1 of the parsing.
(It still needs to be kept up to date for stage 2.)

Note also that stage 2 parsing does not need to know the module
type.  To apply the translation table, one would loop through all
Df250PulseIntegral objects (for example) and use the rocid/slot/channel
values stored in them to identify the detector system and indexes.
These are what's needed to create the appropriate "Hit" objects
(e.g. DBCALHit).

I know that this is a bit long, but bear with me. If we store the module
type in the data, we don't need to have it in the translation table. We
may still choose to keep the translation table in the inventory database,
but not because we require it to contain module type information that
would have to be stored redundantly were we to keep the translation
table in a different database. In other words, I think we have a bit more
flexibility to choose how to store the translation table without having
to worry that we are duplicating information in multiple databases.

Regards,
-David


On 9/5/12 4:48 PM, Elliott Wolin wrote:
> Hi,
>
> At the Offline meeting Alex asked whether we plan to use the JInventory
> database to generate the translation table needed by offline event
> analysis programs.
>
> The translation table converts from the crate/slot/channel coordinates
> that appear in data files written by the online DAQ system to detector
> coordinates, e.g. package/plane/wire and so on.
>
> CLAS uses a similar inventory database and does this, so we should be
> able to as well, if we want to.  Critical would be keeping the database
> up-to-date at all times, as the translation table would be generated for
> every run.  That is, the database must be modified immediately, without
> fail, if changes are made to the DAQ system.
>
> I've always thought we would do this unless there's a better
> alternative.  We will discuss this at the Online meeting next week.
>
> Thoughts?  Comments?
>
> Thanks,
>
>

_______________________________________________
Halld-online mailing list
Halld-online at jlab.org
https://mailman.jlab.org/mailman/listinfo/halld-online

-- 
---------------------------------------------------------
David Abbott                      Jefferson Lab
Data Acquisition Group            Suite #10
F268 Cebaf Center                 12000 Jefferson Ave.
MailStop 12B3                     Newport News, VA  23606
EMAIL: abbottd at jlab.org
Tel: (757) 269-7190
FAX: (757) 269-6331             URL: http://coda.jlab.org/
----------------------------------------------------------