Linear Collider Forum

Home » Software Tools » LCIO » Meeting Minutes
minutes of meeting 2004-04-05 [message #64 is a reply to message #30] Wed, 07 April 2004 16:30 Go to previous messageGo to previous message
Messages: 80
Registered: January 2004
Participants: FG, TB, HV, RC, NG, GM

Agenda Meeting 04/05/04

1) Status and new Developments

2) Simulator Status (RC's proposal)

3) Reconstruction Data model
a) HepLorentzVectors (FG's proposal)
b) Implementation of Reco model
see posting in forum (Tracks,Clusters,ReconstructedParticles)

4) Redesign of LCIO
I would like to drop the namespace DATA (package
from LCIO. The original intend for that was that users should be able
write their own classes with LCIO by implementing this 'small'
interface. As things are developing the interfaces (in particular for
the reco model) are not really small and I don't think that people will
want to use their own implementations of the LCIO API.
The advantages are:
- clearer design (on level of abstract inheritance less)
- improved performance (less virtual function calls)
- no 'dublicate' methods any more (getParents/getParentsData)

If we then decide to create the complete API. i.e. including
the set methods with the AID tool we are left with a much cleaner
design: only one abstact API (common in Java and C++) and one
concrete implementation.
Instead of having three different levels, e.g.
MCParticleData, MCParticle and MCParticleImpl and having to cast
between those frequently, there will only be the
MCParticle interface that is used for reading and writing the objects.

Once jdk1.5 is released Java will also have typed collections and then
we could probably avoid casts in user code completly, which reduces run
time errors and increases readability of the code.

5) time line for new release
(Java,f77 reco model)

6) other issues

decisions and action items are *

9:08 AM 4/5/2004

1.) NG: working with Willy Langeveld to release lelaps with LCIO.
Implementation exists, undergoing QA on the output.
Part of QA involved checking for memory leaks.
valgrind pointed out several, which were reported to the
forum, and have been fixed (by FG) in latest head cvs version.

* agreed to run valgrind before any production release.

GM: Paolo is working on MOKKA LCIO output. Aim is for a
release by Paris.
GM: working on CALICE TB setup.

* Handling of secondaries should be consistent between G4 programs.

RC: code which he has been developing is available in cvs,
will work on documentation.

2.) discussion of status bit:
FG: would have expected a simple enum of the different
RC: hoping to keep it simple, but if people want more info,
one can go in to great detail as to what happened.
another byte could be reserved for more information
FG: would like to reserve byte or 16bit word to accomodate
more detail at a later time.
bit 31 already defined? for endpoint?

*FG will double-check which bits are currently being used.

RC: vertex not being endpoint of parent is very important.
has only implemented creation bits, still working on
the destruction bits. close to being able to release
lcs with these things implemented and writing out lcio.
has been doing QA on the output lcio files, looks good so far.
would like to have implementation for the status bits
as soon as possible.
*FG will try to implement in next few days.
* should implement methods which insulate user from the specific bits

RC: Proposed only creating MCParticle from albedo particles
if they leave energy in a sensitive tracker.
* agreed.

RC: Can get hits in tracker sensitive volumes which are
attributed to neutral particles. Happens when secondaries are
produced below the threshold for creating a new particle.
Proposed creation of MCParticles for those particles which
arise from neutrals and cause tracker hits. Provides a common
way to handle "spurious" hits in tracker sensitive volumes.

TB: what is overhead for this?
RC: doesn't think this is a big deal.
FG: how many particles would this add to the event?
RC: maybe 20 in a ttbar event.
*sounds reasonable to implement if possible and overhead is indeed low.
* benefit is that tracker hits always point back to something reasonable

3a. FG HepLorentz vector for LCIO.
Main idea is not to inherit from CLHEP, but have a class
which is instatiated from the LCParticle, which can be
turned into a 4-vector, keeps 4-vector object separated
from the LCParticle, but have different ways to access the
attributes of the particle.
perhaps drop the operator overload, since not available for java anyway.
TB: fundamantal decision whether to inherit from 4vec or not.
need to decide soon.
FG: inheritance from CLHEP is not a good idea, since many of
the methods change the content of the LCParticle.
TB: LHC and BaBar both inherit from CLHEP. so could be done if careful.
NG: must be careful then to know exactly whether one is dealing
with a transient copy of the data, or is mucking around with the
TB: points to as example.
FG: thinks this would be a thin layer on top of lcio implementation.

* we need to think about this in some detail and come to a decision fairly soon.

forum issue:
TB: subscribed to several topics, but not receiving email updates from forum.
* check with Tony to see if there are any setup issues.

3b implementation

FG: implemented tracks, clusters, reconstructedparticle and typeid.

NG: tracker hits and calorimeter hits not yet defined. Do we need to
define an interface or abstract base class for these?

FG: thought there would NOT be a common tracker hit
handle by storing the collection types, and use integer indices to
point to hits and clusters within the collections.

NG: what would a global track return as a list of hits?
e.g. TESLA track could have
CCD pixel hits, intermediate silicon strip hits, tpc hits, straw chamber hits
FG: track would return a list of collection types. one would iterate over
this list, then fetch the hits for each separate type collection.
NG: not too happy with this, since it imposes a very tight coupling between
specific types of hits and reconstruction code. i.e. need to know in
track finder or fitter that one is dealing with a detector-specific
type of hit. Will give some more thought to this.
NG: calorimeter cluster also defers this question of a base calorimeter hit or
interface, but it seems clearer that there is probably going to be only
one calorimeter hit type on which we can agree.

* this still needs some serious thought, as it addresses a very fundamental issue.

FG: would like to use pointers, but sio requires pointed-to and pointed-at
words, which is seen as too costly an overhead, so stick with indices.

*general consensus that we should follow Frank's proposal.

5.) FG: hoping to get a beta release with recon model by beginning of next week.

TB: Would like to announce at Paris that a reco model is available.
First design exists, first beta implementation hoped for. Expect user input,
so would be nice to have the code available.
*Stress that both design and implementation are first iterations and that feedback is requested.

Meet next week Tuesday (April 13).
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: Thu Dec 12 13:15:40 Pacific Standard Time 2019
.:: Contact :: Home ::.

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