Linear Collider Forum

Home » Analysis and Reconstruction » EUDET Telescope » RunHeader EUDET specific parameters
RunHeader EUDET specific parameters [message #683] Mon, 05 February 2007 03:33 Go to previous message
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,

I'm trying to figure out which are the specific parameters we would like to save within the LCIO RunHeader.

The LCIO data model allows the user to add "named" parameters of integer, float and string type to the run header, the event and to each collection. The basic underlying idea is to store parameters into a map and use the name key to retrieve them.

Without breaking any LCIO rules, I've prepared a class EUTelRunHeaderImpl with no data members but with methods to get/set our specific parameters into the run header. For example, instead of writing:

float softVersion = runHeader->getFloatVal("DAQSWVERSION");

one can use

float softVersion = runHeader->getDAQSWVersion();

This may be very useful when the number of parameters grows up and we have always to remember the correct parameter name to set/get it. I believe that this is especially true for people involved in the DAQ software. If you don't agree, you can also not use it !!! Smile

Now, here comes a list of parameters I've already implemented for the run header:

  • RunHeaderVersion (float)
  • DateTime (string) a time stamp in human readable format
  • DataType (string) a flag to indentify real DAQ data or simulated or converted...
  • DAQHWVersion (float) It represents the version of the hardware part of the DAQ.
  • DAQHWName (string) It is the name of the DAQ HW system. In principle we can have many!
  • DAQSWVersion (float)
  • DAQSWName (string) as above but now for the software part of the DAQ
  • SimulSWVersion (float)
  • SimulSWName (string) as for the DAQ but here for the simulation software used for data generation
  • GeoID (int) an identification number to identify the run geometry within the geometry database
  • NoOfDetector (int) this is the number of detectors in the current run. It is redundant since this information is also stored within the geometry db, but at least for on-line monitoring I believe that access to an external database shouldn't be compulsory. This number may also not corresponds to the number of planes.
  • MinX, MaxX, MinY, MaxY (vector<int>). To properly store data into a Tracker(Raw)Data object we have to use the CellIDEncoder. This requires to know the first and the last pixel of each sensors along both directions. MinX/Y may be different from zero, when there are multiple sensors in a plane, or when we consider a detector one channel (as in Mimostar2).

Should we add some standard field about the DUT? Adding other parameters is always possible.

Please comment this list and add what is (for sure) missing!




Read Message
Read Message
Previous Topic:LCIO: first trial and first questions...
Next Topic:Important steps toward the EUDET telescope analysis
Goto Forum:

Current Time: Sun Dec 15 17:54:13 Pacific Standard Time 2019
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software