Linear Collider Forum



Today's Messages (off)  | Unanswered Messages (on)

Forum: EUDET Telescope
 Topic: TB1 data taking phase over
TB1 data taking phase over [message #924] Wed, 20 June 2007 05:36
antonio.bulgheroni
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,
this is to inform all of you that our first test beam is now over, at least for what data taking is concerning.

We were able to run the brand new analysis software fully compliant with the ILC standard tools and we are now producing the first very fresh results. Few of them have been presented already this morning in DESY during the summary meeting (agenda & talk available at indico server).

Now data are migrating to the GRID for storage and continue the analysis also from outside DESY.

As soon as they will find their final location, I will post here a small how to access to them and a description of the dataset catalog.

Thanks to everybody for the very fruitful collaboration and stay tuned to see more.

Cheers,

Antonio on behalf of the testbeam24 crew!


----

Antonio
 Topic: 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

 Topic: ilcinstall: configuration file for Eutelescope
ilcinstall: configuration file for Eutelescope [message #849] Mon, 14 May 2007 03:08
antonio.bulgheroni
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,
this is just to inform you that, thank to the new ilcinstall script, it is possible to install all the ILC software tools in a single process including additional Marlin packages as Eutelescope.

In the attached file, the configuration script I used to install all the ILC software together with the Eutelescope package.

Cheers,

Antonio

  • Attachment: install.cfg
    (Size: 2.30KB, Downloaded 1436 times)
 Topic: Important steps toward the EUDET telescope analysis
Important steps toward the EUDET telescope analysis [message #721] Mon, 19 February 2007 06:17
antonio.bulgheroni
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear All!
This short post to announce that we are very close to the first release of the EUTelescope Marlin processors. The code comes with doxygen documentation, but since we still don't have a place to publish it, I will try to describe here what has been already implemented and what is still missing. For the time being I tried to avoid ROOT linkage and I'm using AIDA for histogramming.

This is what we already have:

  • EUTelSucimaImagerReader. This is just a test to implement the on-line conversion of the standard SUCIMA DAQ format. Marlin reads an event in the SUCIMA DAQ format and converts it on the fly into a LCEvent. In principle we can implement a reader also for the IRES USB Imager board.
  • EUTelPedestalNoiseProcessor. This processor calculates the pedestal and the noise value of each pixel of each detector in the telescope. Few algorithm have been implemented and waiting to be fully debugged. The results of this processor are saved into a "Condition" file (it can also be a database entry, but not sure it is really needed).
  • EUTelCalibrateEventProcessor. This processor removes the pedestal from the current rawdata and eventually suppress the common mode. The output of this processor is a collection of TrackerData object, one per detector, with the data ready for the cluster search.
  • EUTelClusteringProcessor. This processor looks into each detector TrackerData for group of pixels passing the cluster selection cuts. The output of this processor is a collection of TrackerData containing only the clusters.


What is missing:

  • EUTelAutoPedestalProcessor. This processor will be used with self-biased pixel detectors in which there is actually no need for a real pedestal calculation. The pedestal and noise values for each pixel can be initialize to a reasonable value and then, during the first N events updates to the correct value.
  • EUTelClusterMergingProcessor. This processor will calculate the distance between clusters belonging to the same detector. In the case the two clusters are touching each other, something should be done to separate them. Probably not really needed in a telescope setup where the number of clusters per plain should be sufficiently low.
  • EUTelDataQualityMonitor. This processor should take as input the clusters provided by the EUTelClusteringProcessor and fill in sets of histograms/profiles/distributions... to cross-check the data quality at the detector level. Typical examples are the SNR for each detector, the beam profile, the eta function...
  • All the remaining track finding / fitting stuff.
  • Interfacing to the geometry database.


You can download the source code from here or via anonymous CVS. Once you have the source code, uncompress it into $(MARLIN)/packages and type make from the Marlin top folder.

Type make doc to produce the documentation.

To produce some example files browse to the $(MARLIN)/packages/Eutelescope/test and read the README files.

Please give it a try and let me known what you think about. Your feedback is very well appreciated!


Best regards,

Antonio


Current Time: Mon Jul 23 08:40:18 Pacific Daylight Time 2018
.:: Contact :: Home ::.

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