Linear Collider Forum



Home » Analysis and Reconstruction » Tracking & Vertexing » PulseFinder
PulseFinder [message #515] Mon, 19 June 2006 01:12 Go to next message
mjanssen
Messages: 9
Registered: February 2005
Location: DESY Hamburg
Hi all,

writing the PulseFinder some question came up.
1. a TrackerPulse has also the possibility to store TrackerData, so the ADC spectrum which belong to the pulse. If the data are not zero suppressed, it make no sense to store the hole spectrum.
If one split the spectrum, it is necessary to store the created objects in a new collection. How should this collection be named.
2. after the transformation in to pulses the data (ADC-Spectra) which do not belong to a pulse are no longer needed. Should they be deleted (which is not foreseen in Marlin)
(the some question came up in the TrackerRawDataToDataConverter and other converting processors)
3. I will implement a simple threshold method which can deal with positive and negative signals. When should the double-pulse candidate bit be activated?


Matthias Enno Janssen
DESY FLC
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812
EMail: matthias.enno.janssen@desy.de
Web: http://www.desy.de/flc

Re: PulseFinder [message #517 is a reply to message #515] Mon, 19 June 2006 02:07 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hallo Matthias,

1. We need the extra collection because the pulse only stores a pointer, and the object it points to must be stored somewhere else, right? How about "TPCDataInPulses"? This collection might never be used itself, because usually this data will be accessed using the pulse.

2. For not zero suppressed data only those pulse spectra belonging to pulses should be stored in the collection from 1.
For the zero suppressed version this information is the TPCData (or part of it if not all entries give valid pulses). But the TPCData should not be made transient.

For the converting processors the output of this processor is transient, so there should always be a processor after the converter which does something with the converted data. Then the original (not converted) data and the data after the next analysis step is on disk, but not the converted data. The converter really should be a dump converter and not do any modification to the data.


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: PulseFinder [message #518 is a reply to message #515] Mon, 19 June 2006 02:11 Go to previous messageGo to next message
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
Hello,

I would like to add one more question concerning TrackerPulses.
There are types of readout which do not provide Tracker(Raw)Data.
For those readouts, the raw data can directly be stored as TrackerPulse. But this raw data does not yet include any corrections (contrary to our convention for TrackerPulses).

Shall we add a collection "TPCRawPulses" for such cases?

Concerning Matthias' first question, I agree that only the "interesting" part of the pulse spectrum should be stored.
What about "TPCPulseData" as collection name?

Question 2:
What do you mean by "delete"? Delete from where?

Cheers, Peter
Re: PulseFinder [message #519 is a reply to message #518] Mon, 19 June 2006 03:52 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Does the readout provide quality flags for the pulses? If not, how about using TrackerData with only one entry in the chargeValues? Then it should be possible to use the default electronics channel by channel corrector, for instance. (The pulse finder should not have any problems with this).


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: PulseFinder [message #520 is a reply to message #519] Mon, 19 June 2006 08:56 Go to previous messageGo to next message
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
Using TrackerData (which contains partially corrected data) for raw data storage would not change anything. You would still store uncorrected data in data structures which are expected to contain corrected data. And using TrackerRawData is not possible either since it only offers ints (rather than floats) to store the pulse information. This is not suitable for electronics like those based on TDCs.

Peter
Re: PulseFinder [message #521 is a reply to message #520] Mon, 19 June 2006 09:22 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
So one will need a processor which brings the TDC data into the "default" reconstruction chain, and the collection name indicates that there is something special about the collection and it does not follow the conventions (as you proposed using the special name "TPCRawPulses"). But I still think this should happen as early as possible to avoid double code. ChannelByChannelCorrector and PedestalSubstractor run on TrackerPulses. They have to be reimplemented for the TDC if you use TrackerPulses.

How about "TDCData"? To be correct the raw data collection then should be named "FADCRawData". And both end up in the (electronics calibrated) "TPCData".

Greetings

Martin

(btw. Does the TDC need pedestal correction at all?

[Updated on: Mon, 19 June 2006 09:25]


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: PulseFinder [message #523 is a reply to message #521] Mon, 19 June 2006 11:11 Go to previous messageGo to next message
wiene
Messages: 23
Registered: June 2006
Location: University of Bonn
The re-implementation of the correctors is a strong argument to move the raw data of such readouts into TrackerData objects with special collection names.

I would not suggest to use collection names like "TDCxxx" because Timepix readouts will probably use the same data flow as the TDC based ones.

Peter
Re: PulseFinder [message #541 is a reply to message #518] Mon, 03 July 2006 01:49 Go to previous messageGo to next message
mjanssen
Messages: 9
Registered: February 2005
Location: DESY Hamburg
Hi Peter,
hi Martin,

sorry for answering so late, I thought I will be subscribed automatically to the the threat I created , but Somethings went wrong.

A new idea came in my mind, which solve some problems, and make things more clear.
We should split the PulseFinder in a ZeroSupressor (only threshold based search) and a PulseCalculator (which create a pulse out of every TPCData object (which is now zero suppressed)
It will not split double-pulses, but mark them, as it is foreseen in the pulse finder.

The clarify question 2: In some cases (non zero suppression by DAQ) in the LCIO file the full ADC spectrum is stored. This information are no longer needed after the zero suppression and therefore should not be stored in the new output file. Of course the inputfile will not be changed.

cheers Matthias


Matthias Enno Janssen
DESY FLC
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812
EMail: matthias.enno.janssen@desy.de
Web: http://www.desy.de/flc

Re: PulseFinder [message #542 is a reply to message #523] Mon, 03 July 2006 02:05 Go to previous messageGo to next message
mjanssen
Messages: 9
Registered: February 2005
Location: DESY Hamburg
one year ago, the idea was to store the TDC data directly a TrackerPulse.
The processing chain will be different for the TDC data till the TrackerPulses. This means that all correction will be differend for the TDC data. I don't know which correction must be applied.

The steps after the PulseFinder (on corrected TrackerPulse) should be the same for TDC data and FADC data.

The objects containing pedestal, mapping etc. can be the same in both cases.

cheers Matthias


Matthias Enno Janssen
DESY FLC
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812
EMail: matthias.enno.janssen@desy.de
Web: http://www.desy.de/flc

Re: PulseFinder [message #543 is a reply to message #541] Mon, 03 July 2006 02:08 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hello Matthias,

as LCIO does not provide the possibility to read more than one file simultaneously, you can not access the non-zero-suppressed data if something strange happened during zero suppression and the original collection is not saved. So I think the data should be stored, even if it is a waste of disk space, as long as the shortcomings caused by SIO are not solved. (If you really run out of disk space / have file size problems, you can turn it off in this special case only).

Greetings

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
delete a collection [message #544 is a reply to message #543] Mon, 03 July 2006 02:55 Go to previous messageGo to next message
mjanssen
Messages: 9
Registered: February 2005
Location: DESY Hamburg
Hi,

As I discovered today Marlin provide the posibility to not store collection in the output file.
The LCIOOutPutProcessor has two new optinal parameters:
# drops the named collections from the event
# type: [StringVec]
# example:
# DropCollectionNames TPCHits HCalHits

# drops all collections of the given type from the event
# type: [StringVec]
# example:
# DropCollectionTypes SimTrackerHit SimCalorimeterHit

So that is the solution for some of our problems.
The question is if we still need the SetOutputTransiant Parameter in our processors?

cheers Matthias


Matthias Enno Janssen
DESY FLC
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812
EMail: matthias.enno.janssen@desy.de
Web: http://www.desy.de/flc

Re: delete a collection [message #545 is a reply to message #544] Mon, 03 July 2006 03:11 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
If I remember correctly, there should be some processors which produce transient data by default (those which only do dump conversion for instance). These processors should have the SetOutputTransient parameter to switch off this feature (or should it better be called SetOutputNonTransient?). All other processors don't need it any more, as Marlin already provides the functionality.

Greetings

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: delete a collection [message #546 is a reply to message #545] Mon, 03 July 2006 04:20 Go to previous messageGo to next message
mjanssen
Messages: 9
Registered: February 2005
Location: DESY Hamburg
Yes, I agree with you, only the processors, which write transient output, should have a flag to deactivate this.
As fare as the normal condition for Marlin output is non transient the flag should be named SetOutputTransient, but the default value will be 1 (=true).

cheers Matthias


Matthias Enno Janssen
DESY FLC
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812
EMail: matthias.enno.janssen@desy.de
Web: http://www.desy.de/flc

Re: PulseFinder [message #580 is a reply to message #515] Tue, 08 August 2006 12:30 Go to previous message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
Hello,

I noticed in PulseFinder there is a possibility the TrackerData is stored in a separate collection but it is not associated with the TrackerPulse it was used to create.

Should there be a line similar to:

newPulse->setTrackerData(newData);

near line 220 in PulseFinder.cc?

Thanks!

- Jason Abernathy
Previous Topic:TPCCondData: TPCConditions and ChannelCorrection
Next Topic:MarlinTPC on ilcsoft web site
Goto Forum:
  

[ PDF ]

Current Time: Sat Feb 22 08:37:55 Pacific Standard Time 2020
.:: Contact :: Home ::.

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