Linear Collider Forum

Home » Software Tools » LCIO » Meeting Minutes
Minutes 2004-07-20 [message #120 is a reply to message #30] Mon, 02 August 2004 08:04 Go to previous messageGo to previous message
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Minutes LCIO Meeting 07/20/2001


1) Status
a) f77
b) java
c) cpp

2) Discussion on LCRelation

3) ParticleID in Track and Cluster

4) Schedule for next (beta) release

5) AOB


HV: some minor bugs fixed. Working in Mokka/Brahms LCIO interface.
TJ: nothing new. What is the default value for MCParticle::simulatorStatus,
e.g. in fast simulation ? General agreement that 0 should be used.
FG: added LCParameters to LCEvent and LCCollection in java and cpp.
Implemented new proposal for relation handling.

2) FG: proposal for LCRelation: have simple class for the relation itself as
proposed by TJ, called LCWgtRelation (to avoid name clashes) and store
those in normal LCCollections. Use additional navigator classes to lookup
relations conveniently and efficiently. For efficiency reasons have two
implementations for navigating the two directions (from-to/to-from) of the
TJ: This is not clear to the user, when to use which implementation.
Prefers to have one symmetric implementation for the navigator/relation.
FG: Thinks this causes performance costs.
TJ: Can be implemented in a way that maps are created only when needed.
FG: Could implement symmetric navigator in current C++ proposal.
TJ: wants to go back and see how relations might be used and how the
proposed designs would work in practice.

3) RC: In principle ParticleID used for ReconstructedParticle could be used
for Tracks and Clusters as well. Would need way to tell whether typeID is
PDG code or something else.
FG: Currently not possible, would need additional attribute or could use
collection parameters to encode this.

4) have beta release by Aug 20th (one week after FGs visit at SLAC)

5) TJ: Need convention on how to use parameters inn Run,Event and Collection
to encode type bits etc. -> will make proposal.

TJ: Wants to replace LCObject in Java version with java.lang.Object. This
would enable users to store arbitrary data objects in the event/collections.
FG: This removes the possibility to implement common code for LCObjects,
e.g. reference counting or uniqueID, not sure whether this is needed at all
for Java.
TJ: needs to go ahead and implement it in order to see the impacts.

next meeting not scheduled - sometime after 08/13/2004
Read Message
Read Message icon2.gif
Read Message feedback.gif
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:segfaulting PIDHandler in python
Goto Forum:

Current Time: Sat Dec 14 00:12:52 Pacific Standard Time 2019
.:: Contact :: Home ::.

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