Linear Collider Forum

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

Forum: LCIO
 Topic: SIOWriter couldn't write event header
SIOWriter couldn't write event header [message #2236] Wed, 01 August 2012 09:50
Messages: 13
Registered: June 2008
Location: LYON
Dear all,

Trying to run 2 processors in Marlin, the second one being LCIOOutputProcessor, I got a crash at the first event with the following message :

A runtime error occured - (uncaught exception):
lcio::IOException: [SIOWriter::writeEvent] couldn't write event header to stream: _scratch_RawHits_slcio0
Marlin will have to be terminated, sorry.

How could I debug such a thing ? Is there a way to tell SIO to be more informative ?
Is it a usual message if I've not set properly something ?

In case you want to try to reproduce it :
I'm using ilcsoft release v01-14,
I'm running processors from the Trivent package release 8 ( svn co Trivent )
Look into the README file for instructions on how to compile the package.
I'm using the Marlin xml file which is under <Trivent>/steer/streamout.xml where I've uncommented the LCIOOutputProcessor.
The input file I'm using is on the calice grid at /grid/calice/SDHCAL/TB/CERN/PS_April2012/RAW/DHCAL_713775_I0 _0.slcio

Thanks for any advices.
 Topic: const correctness of LCTime
const correctness of LCTime [message #2181] Fri, 22 July 2011 09:46
Messages: 18
Registered: July 2009
Location: Desy

Dear developers.
Would it be possible to declare const the get functions of the LCTime (and whatever other class IMHO) so that they can be used in a const function?
 Topic: Merging reconstructed particles
Merging reconstructed particles [message #2167] Fri, 18 March 2011 02:28
Messages: 4
Registered: October 2008
Location: LAL
Dear LCIO users,

1) I would like to merge ReconstructedParticles which are present in a collection "myParticles" but appear in a collection of composites ReconstructedParticles "myJets" where I have added them via the method addParticles().

My concrete case is for bremsstrahlung photons that I want to add to their electron :
- If I do electron.addParticle(photon), then remove photon from "myParticles", am I sure that the changes are also made in "myJets" collection ?
Is this the best way to do so ?
Or do I have to create new collections and use new IMPLs ?

2) And by the way, when I am using addParticles(), is there a way to recalculate the energy-momentum without using an IMPL ?

Thank you in advance for you help.
 Topic: lsh: this event does not exist
lsh: this event does not exist [message #1717] Wed, 08 April 2009 07:08
Messages: 66
Registered: January 2007
Location: INFN - Roma3

Dear all,

I'm using the lsh utility to browse the content of a LCIO file.

The problem is that when I cd into the run folder and a type ls I get a list of events (number in square brackets) with the corresponding collection. But when I try to cd in one event I always get the message

this event does not exist

Do you have any idea?



 Topic: easier way to test if an object is in an collection?
easier way to test if an object is in an collection? [message #1684] Sun, 18 January 2009 11:03
Messages: 15
Registered: September 2008
Location: IU

Suppose there is a reconstructed particle found from MCTruthLink;
and there is a collection FTJet1_Selected;

One way to test if the particle is in FTJet1_selected is to iterate over all objects in the collection and see if any of them is the particle;

Are there any better alternatives?


 Topic: lcio cellID1 flag set accidentally
lcio cellID1 flag set accidentally [message #1559] Mon, 04 August 2008 06:25
Messages: 10
Registered: January 2008
Dear lcio users!

I have the problem that the flag to store the cellID1 is set even if my encoding string is exactly 32 bits long. dumpevent shows:

flag: 0x20000000
parameter CellIDEncoding [string]: module:0:6,chip:6:5,channel:11:5,SiPM:16:16,

I set the string via:

LCCollectionVec* pOutputCol =

encodingString("module:0:6,chip:6:5,channel:11:5,SiPM:16:16 ");

outgoingCellIDEncoder(encodingString, pOutputCol);

Where is my error?

Thanks in advance,

 Topic: new release v01-10
new release v01-10 [message #1493] Fri, 06 June 2008 01:07
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available v01-10.
Please check the online documentation at

   - added optional attribute CalorimeterHit::getEnergyError()
       -> set/check flag bit RCH_BIT_ENERGY_ERROR
       request from calice: []

    - optional linkage agains libdcap (dCache) for C++
       -> cmake ..... -DBUILD_WITH_DCAP=1 -D DCAP_HOME=dcap_home ....

    -  added PIDHandler class to UTIL (C++) for convenient access to ParticleID properties of
      ReconstructedParticle (needed for LCFI flavour tag quantities)

    - restructured test programs for C++ (make tests ; make test ; when buit with cmake)

     - made compatible w/ gcc4.3 C++ (A.Bulgheroni)

 Topic: Quality Flag for EVENT::TrackerHit
Quality Flag for EVENT::TrackerHit [message #1454] Thu, 24 April 2008 04:28
Messages: 6
Registered: September 2007
Location: Uni Bonn
Hi all,

for the TPC reconstruction it would be very helpful to be able to store quality information about each TrackerHit.
Would it be possible to implement a new member function in LCIO's Event::TrackerHit that allows to set an integer which contains quality bits?

Thanks a lot,

 Topic: apology: getEventMap() does _not_ cause memory consumption
apology: getEventMap() does _not_ cause memory consumption [message #1411] Wed, 27 February 2008 10:28
Messages: 10
Registered: January 2008
Dear lcio-forum-readers!

In a former thread I claimed, that the direct access feature of lcio causes a huge memory consumption. I want to straighten out, that this is not the case. I used the wrong tools, the wrong way to come to wrong conclusions.

Sorry for the possible confusion.

- Sebastian
 Topic: new LCIO release v01-09
new LCIO release v01-09 [message #1310] Fri, 23 November 2007 09:19
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at

  no changes in file format

   - added event weight: LCEvent.getWeight()  (Java/C++)

   - added LCWriter::setCompressionLevel(int level)  (C++)

   - lcio (java tool) and stdhepjob (C++) improved
       - made compatible with new stdhep files (Java/C++)
       - fill stdhep event weight ( and _idrup / user process id )
       - stdhepjob now build by default (can be used to convert stdhep to LCIO)

   - LCStdHepRdr now fill MCParticle::charge properly (C++)

   - Java uses new sio classes from

   - LCIO (C++) no longer has optional direct dependency on CLHEP
     ( only file is UTIL/LCFourVector.h that can be used in
       programs built with LCIO and CLHEP )

 Topic: Event weight in LCEvent
Event weight in LCEvent [message #1284] Thu, 08 November 2007 09:18
Messages: 138
Registered: January 2004

Hi Frank, some of the stdhep events being generated for benchmarking studies include weighted events. There is no "getEventWeight" method in the LCEvent object. Do you remember if we agreed on a standard location associated with the event to store the event weight? If not should we define one?

 Topic: patch release v01-08-04
patch release v01-08-04 [message #1118] Wed, 19 September 2007 12:04
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new patch release is available from the CVS repository that fixes a few bugs. No changes in the file format or API. If you want to download this release please use the cvs tag v01-08-04. Refer to the documentation of v01-08.

Release notes:

  bug fix release
  no changes in file format and API
  - minor fixes in Java code (JMC)
  - minor fixes for building with cmake

  - changed order of modifyEvent and processEvent in SIOLCReader
    (needed for Marlin Overlay processor)

  - simple shell like tool for browsing lcio files in C++: .../EXAMPLES/
    ( use -DBUILD_LCIO_SHELL=true - requires ncurses and readline )
    [experimental code]

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

I would like to draw your attention to a new topic, "Evolving the Track Class", that I just created within the Tracking and Vertexing forum. As we learn how we want to evolve the track class, we will need to include LCIO people in this discussion.

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: how to use CellIDEncoder and CellIDDecoder
how to use CellIDEncoder and CellIDDecoder [message #992] Tue, 07 August 2007 14:42
Messages: 11
Registered: June 2006
Location: LLR, Ecole Polytechnique

Could someone give me (or point me to) an explanation of how to use CellIDEncoder and CellIDDecoder? I don't quite get how to set the encoding for a new collection, say, an LCCollectionVec of CalorimeterHits when you create these hits from two or more SimCalorimeterHit collections that may have different cell encodings. How is an encoding string, say "i:20,j:20,k:20", being used?

Thanks in advance,

Allister Levi Sanchez
LLR-Ecole Polytechnique
 Topic: LCIO v01-08 released
LCIO v01-08 released [message #648] Fri, 08 December 2006 07:53
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: Building LCIO with CMAKE
Building LCIO with CMAKE [message #471] Tue, 02 May 2006 07:39
Messages: 1
Registered: March 2004
Location: Manchester, UK

After the discussions at the Cambridge meeting I've put together an LCIO distribution that uses CMAKE as the build system. The attached file has the complete setup in it.

It integrates building the manual, python bindings and LCIO. Using the bundled zlib or the system zlib is controlled by a CMAKE switch, as is whether or not to build the manual and python wrapper. You can also choose to use CLHEP or not (there is a USE_CLHEP switch and a USE_CLHEP_NAMESPACE switch - the latter allows use of both the 'old' and 'new' CLHEP libraries. There are some #ifdefs in the code to handle this case).

This setup will produce shared libraries by default, but again it can be switched with a cmake flag. I've also made the necessary changes to the code to build native dlls on Windows systems - sadly the changes needed are not supported by the java ant tool at present and I've not found a way round this.

I changed the directory structure a little to split the core LCIO classes from the fortran and io code. They are built into separate libraries - I make no claims as to whether or not this is a good thing, but it might be a useful discussion point.

This is only the C++ side of LCIO, but integrating the java build ought to be fairly straightforward. Details of the cmake switches are below:

LCSOFT_USE_SYSTEM_ZLIB: ON/OFF (advanced setting); if off, use bundled zlib code

LCIO_USE_CLHEP: ON/OFF (if on, you will need to specify the location of the CLHEP includes and the CLHEP library - or just the vector library if you have the split CLHEP build)


LCIO_BUILD_MANUAL: ON/OFF (latex must be on your PATH. On windows, make sure it is on the user part of the path, not the system part if using visual studio or the figures won't get built into the pdf file)

LCIO_WRAP_PYTHON: ON/OFF (you will need swig 1.3.28 or later and will probably need to specify the location of the swig binary in SWIG_DIR)

To build the code:

On Linux etc.
Make a build directory outside the source code tree. From that directory issue
> cmake -i <path to top of distribution>
and fill in the necessary details. Set the build type to Release for an optimised version or Debug for a debug release).
Then, once cmake has finished, just type make in the build directory to compile. make install will put everything under /usr/local by default but you can change this as part of the cmake -i step.

On Windows:
Run the CmakeSetup wizard to set the build target and options. Then, in the selected build folder open the visual studio top level project, select the desired build type and build the ALL_BUILD project. The INSTALL project installs the compiled binaries.

I hope this is useful for the community - if only as a starting point to help improve the build system and "user experience".


  • Attachment: lciocmake.tgz
    (Size: 1.29MB, Downloaded 1684 times)
 Topic: LCIO v01-07 released
LCIO v01-07 released [message #452] Fri, 31 March 2006 07:30
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: LCIO python bindings available
LCIO python bindings available [message #406] Mon, 19 December 2005 17:45
Messages: 46
Registered: March 2004
Location: SLAC
Hello, LCIO users and developers.

I have made some Python bindings for LCIO using Swig.

A tarball of the LCIO distribution is available here. ython.tar.gz

This contains binaries ***for Linux***.

To test it out after downloading the tarball.

tar -zxvf lcio_adding_python.tar.gz
cd lcio_adding_python/src/python

Or you can work with the bindings interactively.

>> import lcio

And if you need to rebuild it.
make swig

Check the Makefile for variables that can be customized in the environment.

SWIG = name of Swig binary
SWIG_BASE = path to Swig's base dir
SWIG_LIB_DIR = location of Swig's python .i files (SWIG_BASE/Lib/Python)
PYTHON = name of python binary 
PYTHON_INCLUDE_DIR = path to Python include directory

Currently, you need to use the following methods to access collections from the event object.


This is due to the fact that I have not figured out how to make LCEvent::getCollection() return typed objects other than LCObject. (Still working on this.)

Hopefully, the Python bindings can be included in some future LCIO release once the bugs are ironed-out and the interface is cleaned-up.

Please use the forum to request more information or report problems.


Jeremy McCormick, SLAC <>
 Topic: LCIO v01-06 released
LCIO v01-06 released [message #385] Fri, 11 November 2005 11:05
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: LayerEnergy
LayerEnergy [message #302] Wed, 27 July 2005 15:48
Messages: 1
Registered: July 2005
Location: University of Oregon
Hey folks,

I'm looking for a way to get the Energy of a special layer in a Calorimeter from an event in a LCIO file.

Firts, I thought I could use the class CalorimeterCluster, but I haven't found a way to initialize it, because there isn't any class the returns a CalorimeterCluster object in and I cant't call the constructor because I don't know how to handle the arguments.

The only other class with a function LayerEnergy is org.lcsim.recon.cluster.util.FixedConeClusterPropertyCalcula tor which I can't use.

Any suggestions how I can find out the Energy of a layer in a calorimeter?

Thanks for help.

 Topic: LCIO v01-05 released
LCIO v01-05 released [message #277] Tue, 07 June 2005 06:57
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: LCIO on DARWIN
icon2.gif  LCIO on DARWIN [message #269] Tue, 17 May 2005 18:58
Messages: 46
Registered: March 2004
Location: SLAC

I have been working on getting the LCIO C++ libraries to compile for DARWIN (e.g. OSX) in order to create a binary distribution of our simulator package for this platform. We would like to eventually distribute one binary for all OSX users, if possible.

I am building on a 64-bit PowerMac G5.

Here is the uname string.

Darwin [hostname ommitted] 8.0.0 Darwin Kernel Version 8.0.0: Sat Mar 26 14:15:22 PST 2005; root:xnu-792.obj~1/RELEASE_PPC Power Macintosh powerpc

This is the gcc version.

gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

OSX has all the tools required for the LCIO build e.g. java, ant, gcc/g++ and make.

Here are some notes on getting it to build on this platform.

1) There is no Ant target for DARWIN. Thus, I manually go into src/cpp and sio/src and simply type 'make'.

2) By default, the Apple compiler does not define the plethora of nice arch/OS preprocessor variables that one gets on Linux, e.g. __unix__, __i386__, etc. Instead, it only seems to define __APPLE_CC__. So I always use this when checking for the Apple platform in macros.

3) In sio/include/SIO_functions.h...

define SIO_64BITINT as 'long long' as on __i386__, etc.

define SIO_POINTER_DECL as 'unsigned int' as on __i386__, etc.

4) In sio/src/

define endianess to SIO_BIG_ENDIAN.

5) In src/cpp/include/SIO/LCSIO.h...

Define the function

write( SIO_stream* stream , size_t i) ;

because of the 64-bit arch. (size_t != unsigned int on 64-bit)

Currently, it is set if __x86_64__ is defined.

6) In Willy Langeveld's XDR interface, src/cpp/src/UTIL/

Do same defines as Linux/Cygwin.

Also I needed to add

/usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/include/sys /types.h

This is a dirty hack, because this is quite specific to this machine's setup. But otherwise, it was getting usr/include/sys/types.h, which isn't correct! For some reason, the compiler does not include this directory in its default paths.

With the above changes, I was able to produce the sio/lcio.a files.

However, I get this error when one of the examples attempts to link.

ld: archive: /Users/jeremym/work/sim/lcio/lib/liblcio.a has no table of contents, add one with ranlib(1) (can't load from it)
ld: archive: /Users/jeremym/work/sim/lcio/sio/lib/libsio.a has no table of contents, add one with ranlib(1) (can't load from it)

I think the above error could be fixed by adding the "-s" option to the AR command definition to make the library index. (Does Linux do this automatically?)

Any thoughts/advice appreciated.


Jeremy McCormick <>, SLAC

[Updated on: Tue, 17 May 2005 19:14]

 Topic: LCIO v01-04 released
LCIO v01-04 released [message #194] Fri, 11 March 2005 03:04
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: bugfix release of LCIO 1.3.1
bugfix release of LCIO 1.3.1 [message #166] Wed, 01 December 2004 12:41
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new tagged release is available from the CVS repository that
fixes a few bugs. No changes in the file format or API. If you want to download this release please use the cvs tag v01-03-01. Refer to the documentation of 1.3
 Topic: LCIO v01-03 released
LCIO v01-03 released [message #140] Fri, 24 September 2004 10:01
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A new release of LCIO is available for cvs checkout.
Please check the online documentation at
 Topic: Summary of SLAC meeting, Aug 2004
Summary of SLAC meeting, Aug 2004 [message #137] Fri, 03 September 2004 00:48
Messages: 233
Registered: January 2004
Location: DESY, Hamburg

Summary of LCIO-Meeting at SLAC Aug. 06-13, 2004
(F.Gaede, 16.08.2004)

Participants: Ron Cassell, Frank Gaede,
Norman Graf, Tony Johnson

The Meeting was organized around the following list of topics,
most of which have been covered during the week.
In addition we took the time to review the LCIO data model and
API for suitability for reconstruction and consistency.

Topics/Agenda for LCIO-Meeting at SLAC Aug. 06-13, 2004

0) Report from Victoria Meeting

1) Open issues for LCIO release

a) LCRelation: need to agree on common implementation in C++/Java
- C++ : store relations as LCCollections of simple
LCWgtRelationObjects (From,To,Weight).
Use LCRelationNavigator to access/create the relations in a
convenient way ( but not needed)
- Java: two proposals: #one uses only one class to create, store
and access the relations; #two uses also simple relation class
plus additional navigator/handler class but not stored as
simple collections

b) ParticleID (for clusters and tracks)
- proposal for simple extension (FG,TB): have two type words, one
for PDG and on generic type ( getPDG() , getType() ) where the
latter is defined by the user (working group)
- more advanced particle id as discussed at the Victoria workshop
involving logLikelihood etc. -> TJ
- probably we need to remove dEdx from Track as this should be
incorporatetd in the particleId

c) Storage of meta data in LCIO files
- users will need to store additional (meta) data in LCIO files,
such as generator, simulation programs and versions used to create
the file or the encoding of bits in type words like in cluster
and track
- this can be done by using the named parameters now available
in LCRunHeader, LCEvent and LCCollection but we probably want to
provide a naming convention for the standard attributes to allow
programs to access this information in a coherent way
-> need to define these names
-> need way of documenting this
-> need check method isLCIOSpecConsistent() ??

d) UserExtensions
- users have requested a way to store more complex data objects than
int and float vectors. A straight forward (and simple) approach
would be to have an LCUserObject that holds and arbitrary number
of ints, floats and strings with (optional) named access to the
data. The meta information, i.e. the types and names can be stored
in one or more string parameters in the collection in a way that it
is not necessarily needed for reading/accessing the data but
just provides more convenience
- this approach could be extended/replaced in the future by a more
elaborated system that uses e.g. the xml description of LCIO
objects and allows storage of (completely) generic objects
(see 4))

e) Documentation
- as LCIO has been extended and improved we need to clearly document
the intended usage of the classes. This can be either done in the
manual and or in the class documentation of the API.
- in particular it is important to have one definite place where
the specification of a consistent LCIO file is documented. e.g.
an LCIO file has:
+ exactly one MCParticle collection
+ one RecontructedParticle collection holding the complete and
unique list of particles in the event
+ has run headers for every run
+ has meta data attributes as in 1c)
+ ....

f) 4-vector support in LCIO
C++ has some (UTIL) classes that can be used to create CLHEP
4-vectors from ReconstructedParticle and MCParticles (and possibly
Tracks and Clusters)
Will there be a Java equivalent for the next release ?

g) support for having objects contained in multiple collections
- mainly a C++ issue (memory handling)
needed e.g. for candidate lists passed from one module
to the next when LCIO is used as a transient data model

h) need to identify TODOS for Java/C++/f77 implementation
for next release
- release schedule

2) Future developments / new features

a) Storage of user defined types
- it is foreseeable that in the future users might want/need to store
arbitrary types in LCIO. TJ has proposed that a generic mechanism
could be implemented using the xml definition of our objects.
It would be interesting to know how much effort this would be and
on what time scale such a system could be added to LCIO.

b) Convenient/Util classes
- list of wanted/needed features
- how to implement these

c) conditions data in LCIO
- needed/wanted ? -> a) user data

3) Usage of LCIO in lcd framework
- Differences between LCIO classes used in org.lcsim and the
official LCIO classes
- LCIO as transient data model in all applications ?

4) Discussion of common framework
- simulation (geant4)
- reconstruction
- mixed Java/C++ framework
-> technical feasability

6) Discussion of geometry/constants handling
- geometry API (proposal TB)

7) LCIO data catalog
- web based
- grid enabled ?

8 ) LCIO meeting at DESY after/before CHEP in Interlaken ?

Appendix A) Review of LCIO data model/API

B) LCIO interface to stdhep binary file format

------------------------------------------------------------ -----------

0) TJ gave a brief report of what has been discussed at the Victoria workshop
wrt. LCIO. Mainly the ParticleID class has been found to need some
modification in order to be useful (see 1b/A)

1a) TJ/FG agreed to implement relations as a list of simple LCRelation
objects stored in LCCollections. A Navigator class will be implemented in the
UTIL/hep.lcioo.util namespace/package that makes the navigation of such
relation collections easier. There might be a convenient method that returns
the relations with a given name from the event.
TJ will look into this and implement a proposal in Java that FG will adopt for
In general it was agreed that classes in UTIL will not have a common
interface defined using the AID tool.
Nevertheless the idea is that their interfaces are defined similar in C++ and
Java. This is equivalent to what is done now for the set methods in the
implementation classes. Even though these are not defined via AID they are
very similar in Java and C++ as we manually implemented it that way.
If it turns out to be more convenient/efficient to make use of some specific
language features that are not available in the other language this
might be done occasionally in the UTIL package.

1b) As mentioned under 0) there have been discussions at the Victoria
workshop on the suitability of the current ParticleID objects in LCIO.
People familiar with the particle identification used in BaBar suggested some
modifications to ParticleID that we agreed to incorporate in the next release.
See A) for details.

1c) Two different types of meta data can be stored in an LCIO file. One is a
set of attributes that defines the program or algorithm that has been used to
simulate/create the data in the file and the other type is information that is
needed to decode the data itself, e.g. indices of bits in flag words.
For the first type a set of recommended attribute names (keys) has been
agreed upon: GeneratorName, GeneratorVersion, SimulatorName,
SimulatorVersion, ReconstuctorName, ReconstructorVersion, CMEnergy (double),
Accelerator (String) NLC500H, Tesla (etc), PhysicsProcess(es): tt, ee, etc.,
KeyWords: SUSY (etc), Comment, Creator, Requestor, Contact, Date,
DetectorName, FileSize, Events
Identical keywords should be used in the meta data catalog (see 7)).
They will be defined as global constants (probably in the interface LCIO)
and users should be encouraged to use those through clear documentation.
This documentation should be available in the manual and where appropriate
in the direct method API documentation. Users might want to add additional
references to more extended documentation if needed through URLs etc in
the parameters of run headers, events and collections. These will be
'free format' references that will have to be defined within in the
corresponding user community.
Depending on the use case different sets of meta data attributes will be
needed, thus we decided to not enforce the consistency with specification
with a method like isLCIOSpecConsistent().

The second form of meta data that deals with indices of bits in words or
elements in arrays will be decoded in the collection's parameters. For
decoding the position of bits in a flag, a string/int map will be created
through the use of two parallel arrays, one string and one int.
E.g. to decode the track type one could have
TrackTypeBitNames "VXD" "FTD" "SIT" "TPC"
TrackTypeBitPositions 0 1 2 4
(where the values of TrackTypeBitPositions need not be in consecutive order)
To decode the indices in an arbitrary array only a vector of string keys is
needed, where the position of a key defines the corresponding index.
E.g. to decode the number of subdetector energies one could have
Subdetectors "LAT" "ECAL" HCAL" "MUON"
This needs to be clearly documented in the corresponding method description.

1d) A simple form of UserExtensions should be included in the next release.
FG will work out a proposal how to do this. Important is that the file
format will be readily described through the xml description and that the
mechanism can be extended a more general solution in the future. If possible
we will introduce a mechanism that allows accessing the attributes of the
generic objects via strings that are stored in the parameters section of the

1e) The largest part of the documentation should be done in the manual. As far
as needed this documentation can be referenced from within the API
documentation. For the future it might be nice to have direct HTML links
between the API documentation and the manual. This requires however that the
complete documentation will be organized in a self contained tree, so that
these links also work in stand alone (offline) copies of the documentation.
For the next release we agreed to have the manual rewritten in way that it
completely describes every data entity in LCIO, probably in a dedicated

1f) For Java there is a 4-vector class available from that offers
comparable functionality to the one in CLHEP for C++.
TJ will look into how this class can be used in Java in a way that is similar
to the template LCFourVector provided in UTIL. We might have to modify
LCFourVector to not use templates in order to be closer to the Java
implementation. Ideally the 4-vector classes should be 4-vectors in itself and
hold references to the original LCIO object, of type MCParticle,
ReconstructedParticle, Track or Cluster.
In the future we will provide convenient methods in UTIL that create a list
(vector) of 4-vectors from an LCCollection, possibly allowing to pass
a predicate to select a subset of the collection.

1g) Support for collections of elements that are already contained in some
other collection in the event will be postponed until after the beta release.
This poses problems in particular for C++, where the memory handling that is
currently provided with LCIO doesn't allow for multiple containment of one
element within the event.
But also for Java it is not straight forward to define what to do when
persisting the event: either store those references as references or copy the
referenced objects.
One clear solution would be to introduce reference objects (comparable to
the relation objects instead that they only reference one object) that can
be stored in LCCollections. This however needs a bit more user code than
simply allowing multiple containment, e.g.

LCReference* ref = dynamic_cast<LCReference*> ( col->getElementAt(i) ) ;
Track* trk = dynamic_cast<Track*> ( ref->getObject() ) ;
trk->getOmega() ;

This needs to be settled in the future.

h) Instead of identifying open issues for next release a complete review
of the reconstruction part of the data model was done ( see Appendix A).
The time scale for the next beta release was set to be before the Durham
workshop or shortly thereafter.

2a) not covered

2b) Covered in corresponding points, mostly in 1) and A).
One new util method that will have to be released soon is an interface to
stdhep, see B).

2c) For the conditions data it was agreed that in the future one will probably
need to have a system to store and access the information. For the time
being LCIO can be used, either with the existing integer and float vectors
or with the new generic objects (see 1d)).
A more general approach would include storage of generic records in LCIO
files, this however has not been discussed in detail.

3) Usage of LCIO in lcd framework.
The current lcd framework uses LCIO classes but also introduces some wrapper
or convenient classes on top of LCIO. In particular it defines a new event
class LCSimEvent that is capable of holding arbitrary data objects.
These are used to pass event related information from one module(driver)
in the reconstruction onto the next.
It has been agreed that it would be worthwhile to introduce a similar
mechanism for the LCEvent, i.e. the capability to store named pointers to
single objects (of type LCObject). As these can be arbitrary user defined
types, they will only be used as transient data.
TJ wants to continue to include LCIO in the lcd framework to see what
functionality is missing or how convenient the handling of the classes is
and whether convenient wrapper classes are needed or not.
FG would prefer to use plain LCIO in reconstruction (and analysis) code and
introduce convenient methods and classes where needed.

4) Some discussions have been made wrt. to a common software framework.
The SLAC group is working on the LCS geant4 based simulation tool,
that they see as a natural successor to LCDG4.
It is felt that working on a common application or framework doesn't
give everyone the flexibility that is needed. In order to still share
resources it would be possible to have a cvs repository with code snippets
and modules that could be adapted to other frameworks and applications.
As this might not be so easy and straight forward for some problems we could
also work on common algorithms and define how things are to be done rather
then using/providing common code. A good example of this approach would be
the MCParticle link where we discussed within the LCIO group how this
link will have to look like but don't have a single common implementation.
SLAC is also working on a new geometry description (Jeremy McCormick)
that highly parameterizes projective geometries and allows for fast
modifications of the geometry w/o the need to provide new drivers/code.
This geometry package is only loosely coupled to LCS and could in principle
be adopted to other frameworks/applications as well.

As far as the reconstruction is concerned we introduced available
reconstruction frameworks in Java and C++. FG gave a short presentation of
LCIOFrame that is meant to serve as a basis for C++ reconstruction code
that is under development in Europe. It uses plain LCIO as transient data
model. TJ in turn presented the current version of the lcsim framework
that already has some usable reconstruction code in Java available. It defines
a similar structure compared to LCIOFrame but with more callbacks (user hooks)
and a more advanced way of organizing the drivers/modules in a tree like
structure. It doesn't use steering files but uses the Java bean specification
to provide driver attributes either in code in a stand alone program or
via pop up menus when run in JAS.
It was agreed that it would be good to use common or at least similar names
for things in both frameworks, e.g. use Processor for what is now called
Driver and Module respectively. Also we should provide a similar set of user
callbacks in both frameworks. This will make it easier to transform existing
code from one language to the other.
It would also be interesting to see whether a mixed language approach is
a reasonable way to go. TJ and FG will both like to have a closer look
at that option and understand he overhead and implications.

6) The current lcsim framework has a very generic mechanism to provide
meta/conditions data to Drivers/Modules. It uses zip files to store
arbitrary data that can be accessed in initialization. If available property
files are parsed to provide named attributes. The current scheme doesn't use
or define any abstract geometry API as it is a more general approach that
can be used for any sort of information.

7) TJ proposed to set up a common data catalog for existing LCIO files
that are made publicly available. The idea is to use some meta data
description in XML files that uses well defined meta data tags as defined
in 1c). Groups could make these meta data files available at some well
defined URL from where a script could fetch all existing xml files and combine
them in a global data base. This DB will provide a web based search for LCIO
files based on the meta data attributes. TJ will make a more detailed proposal
in the forum.
It was briefly discussed as to whether we could/should use a grid
infrastructure to provide the data files. This however seems difficult at the
time being as US and European groups seem to use different protocols.
This would need more investigation.

8 ) It was envisaged to have another LCIO/Simulation Meeting at DESY
for three days (22-24/09) prior to the CHEP conference at Interlaken,
Switzerland depending on travel budgets.

Appendix A) Review of LCIO data model and API

- will become an abstract calorimeter hit similar to Trackerhit
that can be used in reconstruction
- to be used for calibrated hits (i.e. amplitude in GeV)
- add pointer to RawCalorimeterHit
- add float time

new class for pure raw data:
- int cellid0
- int cellid1 (optional)
- int amplitude
- int time (optional)

- use List/MCParticleVec for daughters and parents

- rename methods getNumberOfElements() to size()
- rename getElementAt() to get() and at()

- change unit of dEdx to [GeV]
- change getType to int and use meta data description
- remove setMethods
- remove pointer to raw hits (use LCRelation)

- replace getParticleType() by Array of ParticleIds
as in ReconstructedParticles
- remove testType( int bitIndex)
- make shape parameters free length array
plus meta data description

- don't use ParticleID create ReconstructedParticle instead
- remove testType( int bitIndex)
- keep dEdx

- replace probability with lnLikelyhood
- add goodnessOfPID as a meassure for the quality of the pid
- have type and pdg instead of typeid
if the PDG is unknown/not used it will be set to 999 999

- remove getType enumerations (constants)
- rename isPrimary() to convenient method isCompound()
returning getReconstructedParticle.size()

- do not require unique and complete list in event anymore
-> users will have to use isCompound() instead !!

- remove getReconstructedParticleWeights()
- remove getClusterWeights()
- remove getTrackWeights()

- remove link to MCParticle completely -> use LCRelation

- add ParticleId* getPIDUsed() method, returning the pid that
has been used for kinematics etc.

- remove set methods ( keep add methods )


B) LCIO interface to stdhep binary file format
It has been agreed that it we like to provide utility code in LCIO
to read in binary stdhep file and create an MCParticle collection from
that analogous to the HepEvt to LCIO code.
RC agreed to look into providing this code for C++.
The API will look somewhat like:

LCStdHepReader stdHepRdr("HiggsPair800GeV.stdhep") ;

while(1) { // some event loop

LCEvent evt = new LCEventImpl() ;

if ( ! stdHepRdr.readNextEvent( evt ) ) break ;

// ... do simulation ...

readNextEvent( evt ) fills the MCParticle collection in the event and
sets the run and event number according to the input event.
 Topic: LCVector classes are now complete
LCVector classes are now complete [message #113] Fri, 02 July 2004 02:04
Messages: 3
Registered: May 2004
Location: DESY Zeuthen
The LCIO vector classes LCFloatVec, LCIntVec, and LCStrVec are now complete. I have added the LCStrVec classes also for the java part and modified the example and to include the LCStrVec class.

 Topic: Reconstruction Data Model - Fortran interface
Reconstruction Data Model - Fortran interface [message #88] Fri, 14 May 2004 10:29
Messages: 3
Registered: May 2004
Location: DESY Zeuthen
I have added to the cvs the Fortran interface for the Reconstruction Data Model.
Usage is demonstrated in recjob.F

Together with this I included support for x86_64 architectures (Opteron). To use the 64 bit mode has still some problems:
- java version "1.5.0-beta" for Opteron (64 Bit) is unstable but works (several trials may be required) - ok., it is a beta release,
- also the newest gcc version 3.4.0 has a bug for x86_64 architectures when calling C code float functions from Fortran (yields always 0 - reported to ).

Using g++/gcc(instead of g77) with the -m32 compiler option works. To do this one has to define the environment variables MY_CXX='g++ -m32' and MY_FC='gcc -m32'.

 Topic: beta release of v1.1
beta release of v1.1 [message #75] Sun, 18 April 2004 11:13
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
A beta release of v1.1 is available via anonymous cvs checkout, tag v1-1beta. It contains a first C++ implementation of the reconstruction data model (Tracks, Clusters and ReconstrcutedParticles).

Please do not use for production.

User feedback is welcome.

Browse the API: ml
 Topic: Building LCIO using Visual Studio
Building LCIO using Visual Studio [message #49] Tue, 23 March 2004 11:31
Messages: 80
Registered: January 2004
Documentation for building the C++ LCIO libraries and examples
using the Visual Studio IDE can be found at:
I'd like to get some feedback from developers before committing
the solution and project files into cvs.
 Topic: Proposal for 4-Vectors in LCIO
Proposal for 4-Vectors in LCIO [message #35] Wed, 17 March 2004 02:56
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
As has been discussed it would be desirable to provide support for 4-vectors in LCIO. For C++ the HepLorentzVector from CLHEP offers a lot of features in particular the Lortentz transforms.

The initial attempt to inherit MCParticle and Reconstructed particle from HepLorentzVector creates a number of problems:
  1. LCIO will depend on CLHEP
  2. MCParticle already has internal data for (P,E) that is of type float whereas HepLorentzVector has doubles. One could of course change the internal representation but then accessing the data via the LCIO API involves copying or one has to have two synchronized internal representations. Both options are not very efficient.
  3. Inheriting from HepLorentzVector undermines our mechanism for READ_ONLY and UPDATE mode. The user can change the 4Vector part even when the object is readonly (No way to prevent that, except for changing back to the 'const' objects in C++)
  4. After applying Lorentz transforms to the object the original data (from the generator or reconstruction) is lost. If you think of a modular analysis where one computes event shape variables in one module and then uses the transient LCEvent in another module the kinematics is screwed up. Analyses should be done in READ_ONLY mode and add only new collections to the event !

There is a simple solution to the problem: use an LCFourVector that inherits from HepLorentzVector and holds a reference to the
original LCObject. See the simplified UML diagram:

This approach has several advantages:

  1. On instantiation the 4Vector data is copied once and can then be modified (transformed) independent of the original data.
  2. Then new object offers access to all methods of the original object, i.e. it can be used for all further analysis, no need to handle two objects. For C++ overloading the -> operator even allows to replace a pointer to an MCParticle with an LCFourVector object in existing code ! For example on has:
    typedef LCFourVector<MCParticle> MCParticle4V ;
    // ....
    for(  int index = 0 ; index < nParticles ; index++){
    // 'old' LCIO code:
    // MCParticle* part =  dynamic_cast<MCParticle*>( col->getElementAt( index ) ) ;
    // new code with LCFourVector object:
      MCParticle4V part( col->getElementAt( index ) ) ;
      cout <<  " LCIO mass: "  << part->getMass()         
    	   <<  " LCIO E:    "  << part->getEnergy()      
    	   << "  4vec mass; "  << part.m()
    	   << "  4vec E:    "  << part.e() << endl ;
    This even simplifies the lengthy dynamic_cast<> syntax for the user. For Java one would have one additional method returning the LCIO object, e.g.
       MCParticle4V part = MCParticle4V( col[i] ) ;   
       System.out.println(" LCIO mass: " + part.lcObj().getMass() 
                         +" 4Vec mass: " + part.m()  ) ;
  3. The READ_ONLY/UPDATE mechanism is preserved
  4. We can make the dependence on CLHEP (+Java version) optional, i.e. plain LCIO does not depend on anything. Only when users want the 4vector functionality they compile with CLHEP !

So I would propose to go ahead with this approach as it offers all the functionality that we need by avoiding the dependence on an additional library which was the main objection against introducing 4vectors.

Please comment !

 Topic: MCParticle Tree Viewer
MCParticle Tree Viewer [message #33] Tue, 16 March 2004 09:14
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
I have written a small java tool that displays the MCParticle tree
from an LCIO file. If people think this caould be useful it could become part of the Jas3 LCIO-Plugin and/or become part of the LCIO release.
Simply untar the file
Comments are welcome.

[Updated on: Tue, 16 March 2004 09:17]

 Topic: Proposal for Reconstruction data model
icon1.gif  Proposal for Reconstruction data model [message #21] Tue, 24 February 2004 01:21
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
The following graphs show a proposal for the reconstruction data model.
The first is a UML diagram of the classes involved. Note that there
is one main class for all reconstructed particles/objects: LCParticle, that has pointers to tracks, clusters, MCParticles and
LCParticles and the relevant kinematic information. If additional attributes are needed for more complex compound objects, e.g. vertices, they should be implemented as subclasses of LCParticle.
It would be useful if LCParticle (and probably also MCParticle) inherited from HepLorentzVector (and some Java equivalent) to provide users with the 4-vector transformations in CLHEP for LCIO particles.

The second graph shows the collections in the LCEvent and their corresponding types (classes).
The copllection 'ReconstructedParticles' holds a unique and complete list of all the particles in the event as determined by the energy flow algorithm. Particles in that collection must have NULL pointers to other LCParticles but are reconstructed from tracks and clusters only. The primary flag will be 1 for all objects in the list.

Printable versions of the graphs:

Current Time: Sun Feb 23 14:01:48 Pacific Standard Time 2020
.:: Contact :: Home ::.

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