Linear Collider Forum

Home » Software Tools » LCIO » Meeting Minutes
Meeting Minutes [message #30] Tue, 16 March 2004 01:17 Go to previous message
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
minutes of meeting 03/15/04
(participants: NG,RC,GM,HV,TB,SA, FG)

1) Status reports/ New Development

NG: new version of Lelaps fast simulation by Willy Langeveld that writes LCIO files to be released by the end of the week

NG: no time yet to check changes proposed by D.Bailey wrt. LCIO version for VC++. FG: would prefer version w/o additional header files NG: should be feasible
NG: will check project files for LCIO/VC++ into CVS for next release

HV: changes/fixes from DB wrt. f77 had already been incorporated in CVS HEAD

NG: proposal to announce bug fixes available in CVS on LCIO homepage
FG: will do that - and also refer to bug report and forum on the LCIO homepage

RC: work on MCParticle-Track-Link, has preliminary definition of status bits for MCParticle.simulatorStatus
RC: will send email to FG with bit/stati

RC: what is the status of publicly available LCIO files ?
-> need to ask TJ
-> Desy-IT grid group interested in providing grid infrastructure for data files ( should contact TJ)

FG: has little stand alonone java tool to display MCParticle-Tree, used Yappi to display particle names, the JTtree subclass could be used for LCIO plugin (need comment from TJ).
Bug fixes in Yappi needed (will create bug report).
FG: will send around tool soon.

GM: Status of Mokka/LCIO still work to do, details from Paulo who is working on that.

2) Reconstrucion data model

FG: proposal for not inheriting from HepLorentzVector but have
standalone subclass that holds original LCIO particle-object.
Advantages: no need to modify original data when applying transforms, easy to use, no conflicts with READ_ONLY/UPDATE mode of LCEvent (impossible to secure HepLorentz 4 vector data against modification).
Will post detailed proposal with examples to the forum.

FG: Started to implement the Track class in LCIO.
Proposed changes wrt. to original design:
- don't make charge persistent, can be stored as sign of the momentum, have convenient method getCharge() in EVENT.Track API; general agreement on that
- proposal to not store pointers to hits but list of indices, advantages:
* difficult to have set of pointers to different types (SimTrackerHit, TPCHit, ...) as they don't have a common base
* original mechanism to store pointer relationships in SIO is inefficient as it needs to 32 bit words
* indices could probably (Calorimeter?) be stored as 16 bit
FG: will post detailed proposal to forum including use cases from TB

NG: proposal to remove 'get' from accessor method names for reconstruction objects, e.g. have recoParticle->energy() instead of recoParticle->getEnergy().
FG: problem is already released code that has the 'get' in all
accessor methods.
-> need feedback from TJ

3) other points

HV: would like to have web interface to CVS repository, could provide perl scripts for that
-> need feedback from TJ

NG: should we extend the group of participants in regular LCIO meetings ?
all: preference to keep group small to work more efficient on technical details,
encourage people to make use of the forum (and bug report) to discuss LCIO related issues and/or make proposals/requests;
depending on the level of controversy of the topic we can invite people to dedicated meetings

FG: proposal to restart regular minutes of phone meetings and take terms in writing the minutes -> general agreement

next meeting 03/29/04 09:00/18:00

[Updated on: Sun, 16 May 2004 23:15] by Moderator

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: Wed Feb 19 17:13:13 Pacific Standard Time 2020
.:: Contact :: Home ::.

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