Linear Collider Forum

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

Forum: Tracking & Vertexing
 Topic: wrong track direction...? PLEASE IGNORE!
wrong track direction...? PLEASE IGNORE! [message #2350] Fri, 16 January 2015 00:22
Messages: 22
Registered: November 2012
No Message Body

[Updated on: Fri, 16 January 2015 00:44]

 Topic: Problem with PerEventIPFitterProcessor
Problem with PerEventIPFitterProcessor [message #2170] Thu, 24 March 2011 05:02
Hajrah Tabassam
Messages: 6
Registered: March 2011

Hi Experts

There is a problem which I am getting while I am using Marlin. I am trying to run the LCFIVertex package on my samples but getting
this error:

[ VERBOSE "MyPerEventIPFitterProcessor"] A runtime error has occured : lcio::ReadOnlyException: LCCollectionVec::addElement
[ VERBOSE "MyPerEventIPFitterProcessor"] the program will have to be terminated - sorry.
I tried to use LCFIVertex package without this processor and it is working fine.

Is there any suggestion how to solve this problem and second thing what is difference between the default IPVertex and the one reconstructed by PerEventIPFitterProcessor?

 Topic: building LCFIVertex with AIDAJNI
building LCFIVertex with AIDAJNI [message #2078] Wed, 29 September 2010 14:15
Messages: 9
Registered: November 2009

I want to build LCFIVertex package with AIDAJNI. I have ilcsoft version 01-08-01 so trying to install AIDAJNI 3.2.3 there using ilcsoft-install. It says that build is successful

Total time: 7 seconds
sh: gmake: command not found
sh: gmake: command not found
Traceback (most recent call last):
File "/var/autofs/nfs/rawcmos11/voutsi/v01-08-01/ilcsoft-install", line 72, in ?
File " /var/autofs/nfs/rawcmos11/voutsi/v01-08-01/ilcsoft/ilcsoft.p y ", line 423, in makeinstall
File " /var/autofs/nfs/rawcmos11/voutsi/v01-08-01/ilcsoft/baseilc.p y ", line 758, in install
File " /var/autofs/nfs/rawcmos11/voutsi/v01-08-01/ilcsoft/aidajni.p y ", line 71, in compile
os.system( 'tar -xzf %s-%s-'+self.os_ver.type+'-g++.tar.gz' % (self.alias, self.version) )
TypeError: not all arguments converted during string formatting

So I don't really understand if is successful or not. Then trying to build LCFIVertex with

-- Check for AIDAJNI: /rawcmos11/voutsi/ilcsoft/AIDAJNI/3.2.3
-- Java version 1.6.0 configured successfully!
-- Check for JAIDA: /rawcmos11/voutsi/ilcsoft/JAIDA/3.2.3 -- works
-- Check for AIDAJNI: /rawcmos11/voutsi/ilcsoft/AIDAJNI/3.2.3 -- failed to find AIDAJNI AIDAJNI library!!
-- Check for AIDAJNI: /rawcmos11/voutsi/ilcsoft/AIDAJNI/3.2.3 -- failed to find AIDAJNI FHJNI library!!
CMake Error at /rawcmos11/voutsi/ilcsoft/CMakeModules/v01-08-01/FindAIDAJNI .cmake:234 (MESSAGE):
Check for AIDAJNI: /rawcmos11/voutsi/ilcsoft/AIDAJNI/3.2.3 -- failed!!
Call Stack (most recent call first):
/rawcmos11/voutsi/ilcsoft/CMakeModules/v01-08-01/MacroLoadPa ckage.cmake:103 (FIND_PACKAGE)
/rawcmos11/voutsi/ilcsoft/CMakeModules/v01-08-01/MacroCheckD eps.cmake:36 (LOAD_PACKAGE)
CMakeLists.txt:267 (CHECK_DEPS)

So seems like something went wrong at AIDAJNI install.. Have already install java and JAIDA. The path to the AIDAJNI library is also defined correctly.

Any comment is very welcomed,

Thanks a lot

 Topic: LCTPC Conditions Database
LCTPC Conditions Database [message #2032] Wed, 11 August 2010 07:04
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Just to inform everyone:

After a bit of delay, the conditions database for MarlinTPC is partly online:
so far a database for developers is online on the server. Using it you can test code needing conditions data or store conditions data used in your test cases.

This database also serves as kind of a test case for the server setup in general, so please make use of it Smile

The Large Prototype database will go online a bit later.

If you want access or want a separate database for your own small prototype on the central server, please contact me.

Cheers, Ralf.
 Topic: Questions about fitting in MarlinTPC
Questions about fitting in MarlinTPC [message #1976] Fri, 07 May 2010 01:30
Messages: 125
Registered: July 2005
Location: CERN

Christoph had a few questions about the track fitting in MarlinTPC and we both
think they are of general interest. So I answer them here.


1.) Is there a "simple" chi^2 fit processor for straight lines?

You can use the TrackFitterSimpleChiSquareProcessor and fix the curvature to 0. Use the parameters OmegaStart=0 and FixOmega=true.
An other alternative is the LinearRegressionProcessor. The linear regression is equivalent to a chi^2 minimisation with all errors being 1.


2.) A chi^2 helix fitter seems to be implemented in TrackFitterSimpleChiSquareProcessor. Why are defocussing and diffusion parameters of the fit? To fit a function one only needs the functions, its parameters and errors. Why are there other parameters, which are not part of the fit?

The SimpleChiSquare fitter does not use the errors of the hits (for instance to be able to run with the current hit finders which do not set the errors. At least the TopoFinder does not).
In a first version all errors were set to 1, but it turned out that the errors in xy and z can be very different, and they both depend on z.

The SimpleChiSquare fitter estimates the errors as
sigma_xy = sqrt( TransDefocussing^2 + TransDiffusionCoef^2 * z )
sigma_z  = sqrt( LongDefocussing^2  + LongDiffusionCoef^2  * z )

where z is the drift distance. The names are misleading. Originally the idea was to use defocussing and diffusion coefficients from the conditions data. But it turned out that calculating the required values from them is not straight forward.
So "Defocussing" is the intrinsic detector resolution at zero drift, and "Diffusion" is the drift distance (diffusion) dependent part of the resolution.

The documentation is definitely wrong, and we probably should also change the names to be clear.


3.) Is it corrent that neither dEdx (and its error) nor the covariance matrix are stored, or not even calculated?

Unfortunately yes. dEdx is not calculated at all. The covariance matrix is available in the Minuit fit, but it is not stored. The fitter is still alpha and got stuck in the phase when I was struggling that the fit converged at all. In the end it turned out that there was a problem with the start parameters and the pattern recognition (track finding). So the fit should converge, but I did not have the time to finish it yet.


4.) The base class / base fitter is TrackFitterSimpleChiSquare. Is it correct that some things are not cleanly implemented, i. e. hard-coded?

The actual base class is TrackFitterBase. This implements a generic version of calculateResiduals() (residual = distance perpendicular to the helix).
TrackFitterSimpleChiSquare inherits from this and implements the fitting function.
TrackFitterSimpleChiSquarePads inherits the fitter function from TrackFitterSimpleChiSquare, but reimplements calculateResiduals() to return the residuals along the pad row.

Minuit needs limits for the track parameters to converge reliably. These are currently hard-coded:
  1. omega=[-1 .. 1] (only tracks with radius larger 1 mm)
  2. D0=[-100 .. 100] (impact parameter +- 100 mm)
  3. phi=[-2 pi .. 2 pi] (two full circles, no real limit)
  4. tanLambda=[-100 .. 100] (only tracks with less than 100 cm z variation on 1 cm on the xy projection)
  5. D0=[-1000 .. 1000] (only tracks with Z0 +- 1 m)

The only problematic value is D0, since this is a sort of "vertex constraint". In prototype geometry D0 can be large, depending on the orientation of the readout module in global coordinates.
+- 1 m in z is fine for the LP, but still hard coded is not good.
How about using +- 100 mm around the start value from the seed track, for both D0 and Z0?

The other values should be no real limitation, although it should be in the documentation in case someone has problems in exotic cases.



Martin Killenberg

 Topic: Alignment for TPC Modules
Alignment for TPC Modules [message #1946] Mon, 19 April 2010 04:06
Messages: 41
Registered: March 2009
Dear all,

we started a discussion on the topic of alignment in the MarlinTPC meeting of April 15, 2010.

My proposal is to have a baseline geometry description (on the basis of best knowledge at the beginning), encoded in the GEAR xml file.
Then a two-step procedure to
  1. determine the misalignment of the individual modules and store it as alignment constants in the conditions database
  2. apply the alignment during runtime in a second execution on hit level

I see several advantages. We directly have the versioning system of the conditions database, as well as the underlying idea of alignment represented in the right category -- as conditions data. We also stay with the already established reconstruction method in two steps.

Any thoughts, comments?

Please note: for the Hit level alignment, I would suggest an additional flag for the hit (see another forum thread for this).


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
 Topic: VTXNoiseHits
question.gif  VTXNoiseHits [message #1618] Wed, 05 November 2008 13:58
Messages: 6
Registered: January 2008
Does anybody ever used the processor VTXNoiseHits of MarlinReco? Does anybody know how to use that properly?

I am trying to simulate beam background using that processor but my job keeps crashing in PandoraPFA processor. I already changed the density per layer but the crash moves from one event to another.

#8 <signal handler called>
#9 0xf52d669a in PandoraPFAProcessor::CreatePFOCollection ()

If I switch off VTXNoiseHits the job runs smoothly.

 Topic: Default Analyses in MarlinTPC
Default Analyses in MarlinTPC [message #1459] Fri, 02 May 2008 05:59
Messages: 125
Registered: July 2005
Location: CERN
I would like to discuss which default analysis processors should be available for the large prototype (LP) TPC.

Currently available (MarlinTPC r1076):
  • BiasedResidualsProcessor
    Distribution of residuals wrt. track where all hits are included in track fit. Works for straight tracks and helices.
  • HitAndTrackChargeProcessor
    Histograms of charge per hit, charge per track and charge per track length.
  • LinearGeometricMeanResoutionProcessor
    Calculate residuals with the test hit included and excluded from the track fit. Implementation for straight lines using linear regression.
  • LinearThreePointResolutionProcessor
    Calculate residuals using the three-point method. Implementation for straight lines.
  • TimePixClusterSizeProcessor
    Size of clusters (number of pixels and cluster radius) on the TimePix chip
  • TimePixOccupancyProcessor
    Count how many times a pixel has been hit on the TimePix chip
  • TimePixTOTDistributionProcessor
    Distribution of TOT values of all pixels on the TimePix
  • XYZDistrubutionProcessor
    Distributions of reconstructed x, y, and z coordinate of all hits in an event
  • XYZDistrubutionProcessor
    Distributions of reconstructed x, y, and z coordinate of hits on tracks

Also needed:
  • ResidualsReferenceTrackProcessor
    Distribution of residuals wrt. reference track
  • PadOccupancyProcessor

The geometric mean processor should be extended to helix tracks (lower priority since this method is time consuming. The biased residuals are ok for long tracks with many hits and can be corrected by sqrt( nHits / (nHits - nDoF) ) ).

What else is missing?

Martin Killenberg

 Topic: Evolving the Track Class
Evolving the Track Class [message #1092] Tue, 11 September 2007 13:03
Messages: 16
Registered: June 2007
Location: Fermiliab
Dear Colleagues,

I would like to start a discussion about ways in which we can improve the LCIO Track class. The discussion might also touch related classes such as hits and vertices. I have created a wiki page to launch the discussion and I invite all of you to contribute. The page is on the SLAC Confluence wiki at: +LCIO+Track+Class

I prefer comments within the wiki but, if I am in the minority, we can continue the discussion within this forum. I will monitor both the wiki and this forum.

The instructions for getting an account on the wiki are at linked from:


Rob Kutschke

Rob Kutschke Computing Division, MS#234 Fermi National Accelerator Laboratory
Phone: (630) 840-5645 P.O. Box 500
Fax: (630) 840-2783 Batavia, IL 60510
 Topic: New Home for MarlinTPC
New Home for MarlinTPC [message #797] Fri, 20 April 2007 01:37
Messages: 125
Registered: July 2005
Location: CERN

MarlinTPC has a new home. A subversion server has been set up on
The cvs repository in Zeuthen has been taken off line.

A short introduction how to get MarlinTPC and use the subversion repository can be found on

To document MarlinTPC a wiki has been set up:
It provides a user workbook with information how to compile and use MarlinTPC, and a developer workbook with details about processor programming, usage of the version controll system etc.

If you want to be informed about new versions of MarlinTPC you can subscribe to the MarlinTPC mailing list:

If you want to become a registered developer with write access to the subversion repository, please contact me.



Martin Killenberg

 Topic: TrackCheater Covariance Matrices
TrackCheater Covariance Matrices [message #659] Mon, 22 January 2007 10:50
Messages: 5
Registered: June 2006
Location: Oxford

I was hoping to use the TrackCheater processor in MarlinReco but it does not currently provide covariance matrices for the tracks. I see that the helix fitter used returns the diagonal terms, are these sutible for use?
 Topic: INSTALL of MarlinTPC
INSTALL of MarlinTPC [message #549] Fri, 07 July 2006 03:30
Messages: 9
Registered: February 2005
Location: DESY Hamburg
Hi all,

for compiling the Processor of Marlin TPC it is recomended to set:
export LCIO="Where ever it is"/lcio/v01-07
export PATH=$LCIO/tools:$LCIO/bin:$PATH

export MARLIN="Where ever it is"/marlin/v00-09-04

export TPCCondData="where ever it is"/tpcconddata

the submitted exaples work without LCCD and GEAR but you should set:
export LCCD="Where ever is is"/lccd/v00-03
export GEAR="Where ever it is"/gear/v00-03beta
export PATH=$GEAR/tools:$GEAR/bin:$PATH

if you what to use the CondDBDatabase you must set:
export CondDBMySSQL="Where ever it is"/CondDBMySQL

export MYSQL_PATH="Where ever it is"/mysql

I Hope this will help you.


Matthias Enno Janssen
Notkestr. 85
22607 Hamburg

Bldg. 1d / Room 28
Phone: +49/(0)40/8998 3137
Fax: +49/(0)40/8998 1812

 Topic: LCIO classes for Timepix readouts
LCIO classes for Timepix readouts [message #525] Wed, 21 June 2006 11:03
Messages: 23
Registered: June 2006
Location: University of Bonn

I have a couple of questions concerning the usage of the LCIO tracker classes for Timepix based readouts.

The Timepix chip can be run in the following modes
(the mode can be chosen on a pixel by pixel basis):

1. Time-over-threshold (TOT) mode:
Pixel provides total time (in clock counts) over threshold for all hits in a readout cycle.

2. Medipix mode:
Pixel provides number of hits over threshold during readout cycle

3. Timepix mode:
Pixel provides time (in clock counts) between first hit and end of the readout cycle.

4. Forth mode:
Probably not needed for TPC applications.

How shall we store these data in LCIO?

TrackerData (containing the raw data for this particular type of readout technology (and for TDC based readouts) -> see previous discussion):

Mode 1: How shall we store the time information? The time variable expects a drift time, not a TOT (which is more charge information than time information). Do not use the time variable and use the first entry of the getChargeValues() vector to save the TOT - or is there a better solution? What convention shall be use to indicate that the time variable is not used? Set it to a value < 0?

Mode 2: How shall we store the number of hits (n) over threshold?
Fill n TrackerData objects for one channel in the corresponding collection? What charge should they contain in this case?

Mode 3: Here the time provided by the pixels is T_cycle - t_drift
with T_cycle = duration of readout cycle and t_drift = drift time. Storing this information in the time variable (expected to contain a drift time) would be misleading.


Here we should use some of the quality bits to indicate the operation mode of the pixel. Should we use official bits for that or some of those reserved for private usage?
From these bits we can then decide whether the time and charge variables contain useful information (depending on the operation mode).


Here again we should use some of the quality bits to indicate that there might be hits with incomplete information.

Any suggestions, comments, ...?

Cheers, Peter
 Topic: Vertex Class for LCIO?
Vertex Class for LCIO? [message #474] Tue, 16 May 2006 09:54
Messages: 80
Registered: January 2004
Dear Colleagues,
Please see this thread in the LCIO forum for a discussion on whether a new Vertex class is needed for LCIO.
Norman Graf

Current Time: Mon Oct 14 15:34:27 Pacific Daylight Time 2019
.:: Contact :: Home ::.

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