[Halld-online] Generating translation table from JInventory database

[David Lawrence]

Hi Dave,

   In regards to the standard Block header/trailer: Is this something 
that would be added
by the library used by the DAQ prior to the data block produced by the 
module, or is
it something that would come from the module itself? Or, the third 
option, is this something
that would be in the standard Event Building Scheme? (In that case, it 
would still have to
be communicated downstream to the Event Builder from the front end).

   Right now, I don't see anything indicating module type in the data 
format specs for either
the F1TDC or fADC250. I don't see the slot number in the F1TDC spec 
anywhere (though I
have a v2 manual from 2005 which may be out of date). I have a pretty 
old version of the
Event Building Scheme and don't see the module type there, but could be 
missing it. I'd
guess it would come in the Data Block Bank(?).

Regards,
-David

On 9/6/12 3:10 PM, David Abbott wrote:
>    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
>