Linear Collider Forum



Home » Analysis and Reconstruction » EUDET Telescope » EORE file fix
EORE file fix [message #870] Wed, 23 May 2007 04:54
antonio.bulgheroni
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,
during the last meeting in Geneva we concluded that we need something like a BORE/EORE identification. In case the acquisition software was hanging we need to have a sort of "file fix" utility able to scan the LCIO file and eventually append an EORE in the end.

I prepared this utility as a Marlin processor (see details below).

Another important use of this utility is more related to the analysis itself (this is actually the reason why I prepared it Smile ).

The point is the following: since Marlin is "Modular" and we are preparing separate processors for each task, one can imagine to perform the analysis step by step keeping track of all the intermediate output files. Consequently every intermediate files should have the same structure (say with an EORE at the end). This is trivial whenever all records within the input file are processed, but if the user limits the number of record to something below the total number, then the output file won't have the EORE.
In Marlin framework, a workaround can be easily applied implementing an EUTelOutputProcessor inheriting from the standard LCIOOutputProcessor. When the EUTelOutputProcessor::end() is called by the ProcessorMgr, a check on the type of the previous event is done. If this is an EORE then just close the file, if not append an EORE before closing.

From an OO point of view, this just requires to re-implement the end() method keeping all the others as in LCIOOutputProcessor. It is very easy and I've done it already.

From a technical point of view, there a small detail to be fixed in a the original LCIOOutputProcessor implementation. Since I want to derive EUTelOutputProcessor from LCIOOutputProcessor and not from Processor directly, I (think I) need to have also the LCIOOutputProcessor(const std::string& typeName) constructor as it is in the DataSourceProcessor.

This modification along with another change to make the new messaging system working also with const method is included in the attached patch. Frank, can you comment on that? Do you think it is worth or we are moving in the wrong direction?

Thanks,

toto

 
Read Message
Previous Topic:ilcinstall: configuration file for Eutelescope
Next Topic:TB1 data taking phase over
Goto Forum:
  


Current Time: Tue Aug 21 07:38:06 Pacific Daylight Time 2018
.:: Contact :: Home ::.

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