Linear Collider Forum



Home » Software Tools » LCIO » Meeting Minutes
Meeting Minutes [message #30] Tue, 16 March 2004 01:17 Go to next message
gaede
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

icon2.gif  Re: minutes of meeting 03/15/04 [message #31 is a reply to message #30] Tue, 16 March 2004 01:37 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Concerning Normans proposal to drop the 'get' from the simple accessors:
I like the idea of having shorter names for the methods but feel that it would be inconsistent to have a different naming convention for already released classes, e.g. MCParticle and the newer reconstruction objects. Users doing analysis comparing MC properties to reconstructed properties would probably find it odd to write
double eRatio = mcp->getEnergy() / rcp->e() ;
My proposal would be to leave the 'get' in the base interface for persistency (namespace DATA and hep.lcio.data respectively)
and add additional methods with shorter names to the EVEN/hep.lcio.event interface. Thus users can choose whatever names they prefer. A similar approach has been realized in CLHEP where the HepLorentzVector has a number of equivalent methods with different names to ease the use and readability of the code.
-Frank.
feedback.gif  Re: minutes of meeting 03/15/04 [message #32 is a reply to message #30] Tue, 16 March 2004 07:02 Go to previous messageGo to next message
mora
Messages: 48
Registered: February 2004
Location: L.L.R. - Ecole polytechni...
Hello Frank, very good news to place the minutes on the LCIO forum Smile

Gabriel told me about the Mokka/LCIO interface questions yesterday. Let me say that there are at least two main missing features in the LCIO files written by Mokka in the current official release:

1) CalorimeterHits are written as the usual Mokka style. It means, for each PDG partial contribution and for each primary there is a hit object in the collection hit. So several hits for the same cell, if several particles crossed it. I've just rewrote part of this code in such way to have just an entry by calorimeter cell in the collection hit, with several partial contributions. I'm attaching here the same file I sent you before, for our colleagues also, to see if this new format is quite good to be tagged;

2) The MCParticle list doesn't follow the MCParticle-Hit-Assignement proposal you have discussed recently. For the moment it's a kind of ad-hoc solution, controlled by a few command line parameters just to have a tree. But except if you set the parameters in such way to keep all secondaries the tree is unbalanced, so it's not good. I'm planning to implement as near as possible the MCParticle-Hit-Assignement proposal for the next release, if possible still before the LCWS04.

Cheers, Paulo.

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 next message
NormanGraf
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 hep.lcio.data)
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


Minutes:
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
possibilities.
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
data.
TB: points to http://pax.home.cern.ch/pax/ 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.

4.)
*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).
minutes of meeting 2004-04-13 [message #72 is a reply to message #30] Thu, 15 April 2004 17:49 Go to previous messageGo to next message
NormanGraf
Messages: 80
Registered: January 2004
9:11 AM 4/13/2004

FG, HV, TB, TJ, RC, NG

NG: QA on lelaps LCIO output ongoing, Will aim to put into cvs
this week. Plan to run same events through lelaps and lcs
for independent check of lcio output.

FG: Implementation of simulator status bit not done.
working on Reco data model. Modifications agreed to in last meeting
included removing data namespace and java package data.
cleans up API.
TJ: still has some concerns about doing this.
Reason to have data namespace is to be able to use existing classes.
in existing lcd reco, we generate different instances of clusters,
e.g. don't have to tie the data to the data format as long as one has
an adapter. New model would insist that reco directly creates these objects.
FG: could also implement event interface which writes lcio w/o instantiating
lcio classes.
TJ: would like to write a toy reco model to see if he can still decouple
the reco model from the persistence model.
lcio concept has changed over time. would still like to see if
this can be made to work.
FG: introduced pointers to hits. last week used indices, which noone liked
so implemented to use real pointers, adds some to the file overhead,
but seems reasonable.
will also need to point between simtrackerhits and raw tpc hits, so
it makes sense to introduce these pointers.
in current implementation, for raw tpc and cal hits, made the pointer
optional. if only writing out raw data, don't need these pointers.
once these are used, and pointed at, the size will grow. now much more
consistent.
updated the posting in the forum.

FG: generic tracker hits proposed.
NG: concerned that this is OK for 3D hits, or 2D on a surface, but not
so good for 1D measurements. Important point is that what we need now
is something to get started, i.e. recognize the need for such a generic
hit.
*NG needs to write up specific objections to the proposed trackerhit
and propose what that interface should be.
FG: discussion of overall model at: http://desy.de/~gaede/reco_entities.pdf

*important to stress at LCWS to point to a design and even a BETA implementation.
All agreed that overall design is OK

FG: heplorentzvector issues:
1.) not a good idea to inherit from clhep's lorentzvector
has ~80 methods!
no control over access of data, can't impose read-only access
heplorentz methods, e.g. boosting, changes internal data
if ReconstructedParticle inherits from heplorentz vector, then RP data
gets modified.
2.) implemented something which is a class which copies data to the 4vector
which can be used in 4vector calculations, but retains data.
implemented in C++ for MCParticle, and would need only a few lines
of code for RP.
3.) do we want to proceed along these lines?
consensus is to adopt this as a working hypothesis and see how far we
get

NG: Would one iterate over the RP collection and then get 4Vector for each
to feed, e.g. to a jetfinder?
TJ: RP collection could have method such as returnAsHepLorentzvector()
to get a collection of 4vectors.
FG: thinking about object handlers and utility classes, but not yet needed.

3.) release plan:
ETA for java beta release of reconstruction objects.
TJ: before end of month.
1st stage is simply implementation of our current static model
2nd stage would be to implement a toy reconstruction program which
exercises this.
* important thing for Paris is to present the model, and thoughts for
the implementation. Stress that implementation is beta, and subject to change.
FG: started with Java implementation for RP. using Eclipse as IDE.
check in to cvs, we will look at it here.

TB: still experiencing lack of email notification when subscribed
to forum.
TJ: found bug in the emailing code. has fixed and patched local version.
will upgrade when fixed by author.

prototype forum setup, ready for users.


Meet again May 3, after LCWS and after ITRP visit to SLAC.
minutes of meeting 2004-05-03 [message #85 is a reply to message #30] Tue, 04 May 2004 10:09 Go to previous messageGo to next message
NormanGraf
Messages: 80
Registered: January 2004
9:04 AM 5/3/2004
Steve Aplin, Frank Gaede, Harald Vogt, Tony Johnson, Ron Cassell, Norman Graf

Agenda LCIO meeting May 3 2004
================================

1) Status and new developments

2) proposed developments

a) LCRelation - generic, weighted relation between
LCObjects ( e.g. to be used to link to MC truth )

b) additional methods for fast MC:
Cluster.getECalEnergy()
Cluster.getHCalEnergy()
Cluster.getNMuonHits()

Track.getMinHitRadius()
Track.getNumberOfTPCHits()
Track.getNumberOfVTXHits()

3) release plans

4) other issues




1.)
HV: No progress on fortran implementation, busy working on SimDet, etc.
TJ: No progress, but this week blocked off.
aim to have Java implementation done for ANL workshop, but
hope to have good start this week.

FG: News from LCWS04 is good, many groups using
or planning to use LCIO.
No concrete feedback on reconstruction model.
Emphasize that model is beta.
Mokka still missing MC particle link in LCIO.
RC: reminder that MC status word still needs to
be implemented for LCIO.
FG: will work on it this week.


2a.)
FG: introduce concept of LCRelation.
used to link between objects, e.g. raw to processed hit
or raw to MC particle.
BaBar uses something similar. (MCTruthAssociation?)
TJ: SLD had something like this as well.
FG: the relation object is untyped, currently uses std::multimap.
TJ: WOuld like to hide specific implementation from the final user, who
would like to be able to get these links in a
transparent way.

see http://www-it.desy.de/physics/projects/simsoft/lcio/v01-01be ta/doc/doxygen_api/html/LCRelation_8h-source.html


TJ: would like to look at this in more detail. is there an example yet?
FG: see recjob.cc.

TJ: SLD used something like this to associate tracks to vertices,
so concept is useful.

FG: fastMC has no explicit hits or clusters, so need some way to
associate tracks to MC particles.

TJ: will look at and consider Java implementation.

2b.)
FG: Torsten Kuhl, doing some b-tagging jet analysis using fastMC, would
like some convenience methods along the lines of those proposed.
NG: Seems too specific. Let's think about how to abstract this
and make it more general.

3.) targetting ANL workshop.

TJ: as we get close, we will have to decide whether the workshop will
be used to decide on these issues, or whether we will have something
finished by then. In any case, we should have a release candidate
which represents our group's thinking.

4.)

TJ: setting up new enterprise version of bug checking system.
propose moving lcio bug database from freehep to this new system
this week. History should be preserved.

HV: can stop work on SimDet and Brahms, and will concentrate on Fortran
implementation of reconstructed partucle. Should be straightforward.

Meet again Monday May 10, 9AM PDT.
minutes of meeting 2004-05-10 [message #87 is a reply to message #30] Wed, 12 May 2004 00:51 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Minutes LCIO meeting May 10 2004
================================

Agenda:
-------

1) Status and new developments

2) proposed developments - a) and b) continued from last week

a) LCRelation - generic, weighted relation between
LCObjects ( e.g. to be used to link to MC truth )
-> API/ implementation

b) additional methods for fast MC:
Cluster.getECalEnergy()
Cluster.getHCalEnergy()
Cluster.getNMuonHits()

Track.getMinHitRadius()
Track.getNumberOfTPCHits()
Track.getNumberOfVTXHits()

-> need more generic method names (not Tesla specific)


c) proposal: have all user methods in the abstract interface,
i.e. also the set methods. The advantage is that users only have to
use one interface for reading and writing ( the implementation
classes are only needed for object instantiation and even that
could be replaced by factory methods in the future).

-> to be discussed


3) other issues

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

Present: Frank Gaede, Harald Vogt, Tony Johnson, Ron Cassell, Norman Graf

1) TJ has started to implement the reconstruction data model in Java.
Until now implementation of Cluster. Track and ReconstructedParticle
to follow soon.
HV has started to implement the reco model in f77. Working on
a fortran test/example code analogous to recojob.cc.
FG has implemented the simulation status in MCParticle according to
RC's proposal. Modification to endpointIsVertexOfDaughters not correct
according to RC. Logic needs to be: vertexIsEndpointOfParent and
independently endpointIsSet (i.e. the endpoint is not the daughter's
vertex)
FG -> will implement that logic.

2a) TJ: how do users know which relation object in the event holds
which relationships ?
FG: sitatiuon is completely analogous to the collections in the event.
Users have to know the names of the collections they are interested in,
either by definition within the community/working group or by a general
naming convention. A while ago we started to think about such a general
naming convention for collection in LCEvent but did not come to a
conclusion as it turned out to be not so straightforward.
The current proposal for LCRelation allows the users to store more than
one hypothesis for the relations between two concrete types, say
ReconstructedParticle and MCParticle under two different names.

TJ would like to implement the LCRelation in Java to see whether
the proposed API fits our needs and is reasonably convenient for the
user. TJ also wants to compare to existing relationship handling in SLD
software, though this is not OO.
FG: not so easy finding a common API for Java and C++ that handles
relations. For the user it would be more convenient to get all
relations for one object with one method call and the same for the weights.
C++
doesn't have an abstract definition of collections/iterators equivalent
to Java's collection framework. A possible implementation would be to
return an stl::vector<LCObject*> in C++ and a vector (collection) in
Java. (When switching to JSDK1.5 Java could use a vector<LCObject>
closer to the C++ implementation). On the other hand if mostly
one-to-one relations are modelled then it is less convenient for the
users as they have to access the one and only relation as the first
element of a vector.

[FG comment: the current implementation would allow us to use covariant
returns once we switch to JSDK1.5 for the relations, saving the users
from having to apply a cast, e.g.
 LCRelation rel = new LCRelationImpl<CalorimeterHit,SimCalorimeterHit>;
 ....
 int nRel = rel.numberOfRelations() ;
 for(int i=0 ; i<nRel ; i++){
  SimCalorimeterHit* simHit = rel.getRelation( calHit, i ) ;
  ...
 }

whereas now users would have to write:
 SimCalorimterHit* simHit = dynamic_cast< SimCalorimterHit*> (
                               rel.getRelation( calHit, i )  ) ;



I think it would probably be worthwhile to have some discussion of the
merits of switching to JSDK1.5 and using the new features of Java. In
particular having parameterized types (C++ templates) and covariant
returns. If we will make use of those features this would involve some
changes in the API and should probably be done before our next major
release or at least be foreseen for the future.
]

all -> need clarification of the issues soon (before the Argonne
workshop)


2b) It has been agreed to add more generic extensions to Track and
Cluster API than proposed originaly by FG and Thorsten Kuhl:

Cluster.getEnergyFraction( string calorimeterName ) ;
and
Track.getNumberOfHits( string trackerName ) ;

this makes the API more flexible wrt. different detector designs.

FG -> has to check with Th. Kuhl about the necessity for storing the
radius of the innermost hit of a track.


TJ: there are other constant defined in the current implementation that
are not generic enough, e.g. Cluster::ECAL,HCAL,COMBINED,LAT,LCAL.
TJ -> will think of a way to code the subdetector type information in a
more generic way without the need of having to add additional constants
for new subdetectors.



2c) TJ: doesn't like the idea of extending the abstract interface to
also
include the set methods. Most users (in particular users that are less
experienced in sw development) will use the read only interface anyhow.
Expert users (e.g. writing reconstruction code ) can easily use the
implementation classes and apply downcasts if needed. Also this would
make it easier to have additional implementations of LCIO data entities.
For example one could have different Track implementation with a
different parameter set (where the get methods apply the needed
parameter
transformation which would be harder for the set methods).
FG: advantage of having everything in the abstract API is the
possibility
to change the implementation without breaking user code, e.g. we could
introduce some reference counting for memory management in C++. This
would
require that users do not instantiate the implementation classes at all,
but only use corresponding factory methods.
TJ: wants to have a closer look while implementing the reco model in
Java.



Next meeting: May 17, 2004 09:00/18:00 PDT/CET
===============================================

Agenda Meeting 26-05-2004 [message #96 is a reply to message #30] Tue, 25 May 2004 05:40 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Dear all,

as discussed in our last meeting I post the proposed agenda for tomorrows meeting in the forum. (We can probably simply edit this message to include the minutes after the meeting in order to restrict the number of postings to one per meeting).

Agenda Meeting 26-05-2004
-------------------------

1) Status f77, java, cpp

2) Reconstruction data model:

a) TJs comments on Tracks and LCRelations

b) user extensions (see message #94 in this forum)

c) extension to Track: getRadiusOfInnermostHit()

3) Transient LCCollections and multiple containment of one object
Discussing with users from DESY it turned out that they would need the possibility to create subcollections of existing collections, e.g. to analyze e+e->HH->l+l-,jets one would pass a list of all tracks except the two identified leptons to a jet algorithm. Copying the tracks is prohibitive in terms of memory and cpu, simply creating a collection with pointers to existing tracks will cause a segmentation violation (in C++,f77) when the event is deleted, as the assumption is made that every object is contained uniquely in one collection. One way around that is to keep an additional reference to every object in an event and delete objects to wrt. that list. Another way would be to tag the collection as 'transient' and then not delete 'objects' in transient collections. To my mind these are independent concepts and we should implement both: allow one object to be contained in more than one collection and allow for users to flag collections as transient, i.e. they are only used as input to some subsequent analysis/reconstruction module.

4) Other issues



Frank.
Minutes of Meeting 2004-05-17 [message #97 is a reply to message #96] Tue, 25 May 2004 23:15 Go to previous messageGo to next message
NormanGraf
Messages: 80
Registered: January 2004
9:06 AM 5/17/2004
Frank Gaede, Ties Behnke, Harald Vogt, Tony Johnson, Ron Cassell, Norman Graf

HV: fortran reconstruction package has been implemented. See note on LC forum.

TJ: has made good progress on java reconstruction code.
starting from existing LCD fastmc, to at least create smeared tracks,
and clusters. Was sidetracked by development of the event display, which
was necessary to be able to debug the reconstructed objects.
will release code to cvs hopefully today.

RC: has looked at modifications made by FG to the MC status, but has not
implemented code yet. Was sidetracked by bug in cvs head. Now fixed.

FG: cvs head version of lcio doesn't build also due to new java virtual
methods being introduced but not implemented. will try to do so
by tomorrow.

TJ: new version of lcio plugin for jas working with wired event display.
uses hit positions from track and cal hits, but not useful without
some idea of where detector is.
using heprep for wireframe skeleton, and using magnetic field to swim
tracks.
heprep file is quite simple at this point. Default is SDJan03,
Volunteer to help implement other detector geometries until we devise
a way to automatically create these from the geometry system.
FG: created heprep file from Mokka for hcal prototype. for the full tesla
detector, this was 50MB, causing out-of-memory problem in JAS3.
TJ: will probably not want to use the default G4 heprep output. can also
reset default java memory allocation to a higher value.
FG: would be nice to have some way to turn off parts of the heirarchy.
e.g. load detailed G4 heprep, then turn off various items.
TJ: wired4 has a save-as feature, not sure whether this writes everything
or just the visible items.
FG: Mokka has hard-coded drivers with visualization, etc. so painful to change.
TJ: should be possible to turn off visibility within G4. will send
suggestions to local wired/g4 team.
FG: has hardcoded visibility attributes in G4, elements with visibility set
to false don't show up in the heprep file, so this might be possible from
within geant4 using interactive visualization commands.
TJ: picking doesn't seem to work yet, will follow up.
can use both wired3 and wired4 plugins to compare functionality.
TJ: lcio plugin produces hepreps (if wired plugin is available), which are
then used by the wired plugin to display.

TJ: track parameters need discussing. lcio proposal is different from old lcd
lcd: d0 (xy impact parameter)
phi0
omega (signed 1/radius of curvature)
z0
s (tan lambda)

lcio proposal seems to differ even from what we thought it was.

FG: presented proposal at ECFA meeting, but got no feedback. Maybe no one is
paying attention?
NG: should review these parameters and decide what we want.
this proposal is beta, so we should not hesitate to fix this.
TB: tan lambda and 1/pt or curvature should be used.
TJ: some other points: need to get number of degrees of freedom.
reference point is origin, in lcio reference point is explicit.
would like to provide the user with a common reference point, so they
get a commensurate set.
FG: should we have a boolean flag to indicate whether reference point is the pca?
TJ: getType has a bunch of known track types. Would like to either add a few more
or generalize this.
FG: should we use generic strings as was proposed for collections?
NG: Use a DetectorManager class to handle this, using name to discover
the types of collections, detectors, and types of hits in detectors.
FG: will look through code to find where integer constants are being used

TJ: has rearranged the meeting minutes to sit under a common thread in the forum
making them easier to find and follow.
would be more open to post not only the minutes, but also the proposed agendas
and meeting times.

FG: has been discussing with TB how timing is being saved in simcalorimeterhit.
for every simcalhit, time was being stored individually for each MCparticle
type contribution.
TB: MOkka has data saved by pdg type, not each distinct mcparticle
NG: this is somewhat odd, since one would only get one time for all photons
or neutrons, for example, when what one presumably really wants is the
time of deposition from the original, shower-inducing mcparticle.
FG: has updated mokka to store cal information by original mcparticle, but also
can store every secondary deposition as well for detailed depositions by pdg type.
NG: This should only be used for really detailed studies of shower evolution.
Code documentation should note that use of this should be restricted.
FG: CALICE group has also asked for timing information to be added to Cal Hit.
NG: had also come across this missing functionality.


Action items agreed upon:
- use LCD track parameters, i.e. d0, z0, phi, omega, tan lambda
- add getNDF() and isReferencePointPCA() to Track
- add getTime() to CalorimeterHit

Meet again next week, Wednesday, May 26.
Minutes of Meeting 2004-05-26 [message #112 is a reply to message #97] Mon, 28 June 2004 09:14 Go to previous messageGo to next message
NormanGraf
Messages: 80
Registered: January 2004
9:08 AM 5/26/2004
TJ, NG, RC, FG, HV


Agenda Meeting 26-05-2004
-------------------------

1) Status f77, java, cpp

2) Reconstruction data model:

a) TJs comments on Tracks and LCRelations

b) user extensions (see message #94 in this forum)

c) extension to Track: getRadiusOfInnermostHit()

3) Transient LCCollections and multiple containment of one object
Discussing with users from DESY it turned out that they would need
the possibility to create subcollections of existing collections,
e.g. to analyze e+e->HH->l+l-,jets one would pass a list of all
tracks except the two identified leptons to a jet algorithm.
Copying the tracks is prohibitive in terms of memory and cpu,
simply creating a collection with pointers to existing tracks
will cause a segmentation violation (in C++,f77) when the event
is deleted, as the assumption is made that every object is
contained uniquely in one collection. One way around that is
to keep an additional reference to every object in an event
and delete objects to wrt. that list. Another way would be to
tag the collection as 'transient' and then not delete 'objects'
in transient collections. To my mind these are independent
concepts and we should implement both: allow one object to be
contained in more than one collection and allow for users to
flag collections as transient, i.e. they are only used as
input to some subsequent analysis/reconstruction module.

4) Other issues

Minutes:


TJ: updated java version of RECO, cluster, track and some parts of Relation (not IO)
also working on bporting fastMC and reco to use LCIO and newer JAVA version.
FG: was not able to read a file written in C++ reading with Java.
TJ still under development.
HV no updates on fortran version. will update documentation.
try to write lcio output from brahms after reconstruction. eta few weeks
FG: C++ started to implement changes for the track class. not yet checked in.
wanted to use strings for collection types, seems wasteful of space.
could just use an integer type, where user has defined bits.
TJ: no way to interpret bits in an arbitrary file, which is limiting.
would prefer to have something in header to define what the bits mean.
FG: can set only two bits for a track containing VTX and TPC hits.
TJ: would like to be able to use these files even if we don't necessarily
know what the content is or who used it.
TJ: header provides a detector (string), use this name to find out what the detector is
lookup is easier if it's defined by string and not some bitmap.
RC: put bits in for each track, use header to map bits onto names.
FG: had talked about putting some structue into run header.
TJ at a minimum, map bits onto detector names
FG: concerned about disk space, so would like to replace the doca boolean with another bit.
currently proposed to allow user to dynamically define the number of hits per detector.
e.g. getNumHits(string name of subdetector.
NG: should this be in run or event header. probably event, since we ocassionally will strip out events.
TJ names needn't be defined in a generic way, since we need to look up the detector geometry anyway.
how to predefine usable bits, e.g. tracker bits 0-15. so user needn't dump the run header to decode.
FG; doesn't solve problem of how to add a list of number of hits to a track.
currently we would need a string for the detector plus an integer defining the number of hits.
this is expensive.
TJ: comes up primarily for the fastmc or full reco where we drop the hits.
Requires more thought.


2a.) TJ had posted comments on relations.
should we have method to remove relationships?
writing into file relationships between types of class a and b with some weight.
sld found it useful to go in boh directions. current interface sees it as a one-way
relationship. proposes making this two-way. could implement using two maps, one
for each direction, with some additional overhead. can perhaps allow user to define
if relationship is two-way, or use lazy instantiation.
FG;what happens if we relate objects of the same type? be explicit about what direction we are going in.
TJ; make method names somewhat more explicit.
some discussion about api
TJ,FG: will review, propose more meaningfull methods names and functionality
TJ in constructor, not clear on what arguments are: interface name


2b.)
TJ: request #94 wasn't really generic, so prototype wouldn't be a solution.
FG: prototype + lcrelation would. should we try to implement this simple solution?
introducing generic object, leaving out macros
keeping in mind we want a better more felxible solution in the future..
TJ: sounds sensible. so user still needs to some coding, but targets the generic
object, not sio explicitly.
FG: could intorduce mapping to define the data layout of the object.
TJ if string is purely descriptinve would be a lot happier.


3.)
two concepts ,
a.) having collections point to subsets of other collections.
b.) flag collection as transient
FG; think some more aboutthe C++ implementation

TJ in implementing java reco package on top of lcio, started by exposing lcio collections to user.
not convenient, so have now put a thin layer above the lcio collections. thightly couple those to
the IO, but will want to have some layer between the IO and the user.
problems, e.g lcio returns float[] since this makes sense for io, but transient event shouldn't
have to be that tightly bound to the io.
downside is that there is a layer between user and lcio.
FG: would prefer to expose the lcio to the final user.
tj: low-level data interfaces tied to io file format, and higher level event interfaces
both defined by aid files to specify java and C++ implementations. would like to make user interfaces easier to allow them to use natural features of the languages.
leads to divergence, but this gets around coding to the lowest common denominator.

RC: looked at status bits, looks fine. how soon can we make a release?
TJ, FG: propose tagging a version which can be used for lcs developers.
TJ: updated java MCParticle.
Minutes of Meeting 2004-06-21 [message #114 is a reply to message #112] Mon, 05 July 2004 00:54 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Agenda
----------

1) Status f77, Java, C++

2) New developments
a) user extensions
b) transient collections
and multiple containment
c) parameters for collections
events and runs

3) Release plans

4) Other points

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

1) HV: extended and modified fortran examples to be (almost fully)
compatible with the C++ examples.
added documentation for reconstruction data model .
modified array indices to be consistently (1,n)
added LCStrVec for user extensions in C++ and f77

TJ: experimented with Java code for the LCRelations to see how
the interface can be made easy to use and efficient to access
relations in both directions.
also experimenting with user interfaces for other classes, e.g.
stdhep, is there a need for an additional interface that is
exposed to the users or not ?

FG: implemented subdetectorHitNumbers[] and subdetectorEnergies[]
for tracks and clusters respectively and radiusOfInnermostHit for
tracks.
changed int type to flag word for tracks, clusters and
reconstructed particles.
all changes for java, c++, f77.

2) a) Agreement that we would like to have a simple version of user
extension objects, provided that they can be described with our
current XML-dtd.

b) TJ: having mutliple containment of an element in several
collections, is possible in Java anyhow; another way of passing
subcollections between modules would be to add predecate classes
similar to what is available in the LCD-software.
FG: wants to have a look at predecate approach to understand the
benefits.

TJ: wants the possibility to add 'anything' to the event and LCIO
should simply ignore unknown data types during writing.
FG: flagging sth. as transient is more general, i.e. users can
also flag collections of exisiting LCIO classes as transient.
for C++ 'anything' has to be limited to 'anything inheriting from
LCObject'.
need to make sure that LCIO doesn't crash when sth. unknown is
in the event !
all: agreement to add some transient flag to LCCollection.

c) FG: proposes to have simply LCParameters class, holding named
attributes of the base types int, float, string, that can be added
to the LCRun, LCEvent and LCCollection. this can then be used for
example to define the meaning of bits in the type word of tracks,
clusters and recontructed particles.
TJ: need a way to assign/map attributes like 'bit0' to a
particular type of data, i.e. tracks.
FG: would have to be done via meaningful names, e.g.
'TrackTypeBitTPC = 0'
TJ: would like a way to decode this information automatically and
transparent to the user.
FG: don't konw whether this is possible, will probably always need
some additional information from somewhere else.
TJ: could maybe use XML description for that
FG: will implement something so that all can see how things might
work in practise.


3) all: agreement to have another beta release before the Victoria
workshop (July 28) that has all the main new features and data
classes in it

4) plans to have an LCIO meeting at SLAC in the second week of
August (9-13)
Minutes 2004-07-20 [message #120 is a reply to message #30] Mon, 02 August 2004 08:04 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Minutes LCIO Meeting 07/20/2001
===============================

Agenda
------

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


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

1a)
HV: some minor bugs fixed. Working in Mokka/Brahms LCIO interface.
1b)
TJ: nothing new. What is the default value for MCParticle::simulatorStatus,
e.g. in fast simulation ? General agreement that 0 should be used.
1c)
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
relation.
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
Minutes of Meeting 2004-09-14 [message #139 is a reply to message #30] Thu, 23 September 2004 08:45 Go to previous messageGo to next message
NormanGraf
Messages: 80
Registered: January 2004
Agenda LCIO Meeting 09/14/2004
==============================

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

2) Stdhep2LCIO interface

3) Link between Hits and raw Hits
a) TrackerHit->TPCHit: need 1 to many relation, cannot
use LcRelation, because of different types (VTXHit,SITHit,...)
b) CalorimeterHit->RawHit - need only 1 to 1 relation, could in
principle use LCRelation - but should be consistent
with TrackerHit

4) ReconstructedParticle
TB,FG would like to have collection parameter flag
"isUnique" telling the user that the collection at hand
doesn't have double counting (and is complete)
or "isBaseList"

5) Release schedule
FG, TJ: before CHEP if possible

6) AOB


FG, HV, TJ, RC, NG

1a.)

HV has added relations and generic user objects to the f77
implementation, parameters are not yet implemented.
FG points out that the bug tracking forum (with assignments)
is available at http://bugs.freehep.org/secure/BrowseProject.jspa?id=10050
and should be kept up-to-date.
HV expects to be done coding by the end of the week, hopes to have
documentation finished by end of next week.
NG asks if intention is to have output of Brahms reconstruction available
in lcio.
HV yes. currently waiting on resolution of event model and specifics of
some of the objects. e.g. reconstructed particle currently has (x,y,z)
and covariance matrix, but these aren't gaussian distributed, so questions
validity. will need to check on this and decide whether this is what we
want. will not happen before CHEP.

1b.)
TJ went through list of missing Java stuff in the bug reports and put in
essentially everything except relations.
FG checked out cvs head snapshot, run C++ sim and reco jobs, write out
results, try to read using Java version. This failed since relations
are not yet implemented.


TJ points out that trackerhit positions are doubles, but cov. matrix is float.
Is this OK? (probably)

TJ getgoodnessPID is in ParticleID; should this be in ReconstructedParticle?
(yes)

TJ algorithm in PID is currently a String. should this be an integer which
points to a string listed in the event header (yes)
change String getIdentifier into int getAlgorithmID



1c.)
FG believes C++ version is currently up-to-date with all features.
except leave long method names in getters of LCCollection.
except linking raw and generic hits.


Next release will be 1.3. Aim to support 1.0, but not 1.1 and 1.2
for backwards compatibility. plan is to finsh basics this week, and
to discuss advanced topics/usage/utils next week at DESY when TJ visits.


FG urges all to look at updated manual and provide feedback.


2)
RC has started on this, not done yet.
package should go into utils.
discussion of whether stdhep lite classes from Willy Langeveld
should simply be copied or externally referenced. All agreed that
having these classes in multiple locations (lelaps, Mokka, LCIO)
was not clean, but will proceed this way anyway.
need to add float time to MCParticle to allow simulators such as
G4 to properly handle decays.
will aim to finish package by end of next week.

3)
FG points out that the use of LCRelations for TrackerHIts probably will
not work since it will have to point back to different types of hits,
e.g. TPCHits, VXDHits, etc. and we do not want to use LCRelations for
mixed types. We also imagine that TrackerHits may point to many raw data
hits, e.g. a TrackerHit built of many waveforms (TPCHits)


proposal is that CalHit.getRawHit() returns a single LCObject
TrackerHit.getRawHits() returns a vector of LCObjects.

4)
There is currently no way to restrict how users construct collections
of ReconstructedParticles. It could be that various algorithms create
custom collections representing the output of their reconstruction. The
end user will then not know what constitutes either a complete or unique
set of ReconstructedParticles which characterizes the event. The proposal
is to implement two flags. Although there was no strong objection to this
it was felt that it warranted further discussion at DESY next week and
perhaps also on the forum.

5) we are still aiming to release by CHEP.
Re: Minutes of Meeting 2004-09-14 [message #151 is a reply to message #139] Tue, 16 November 2004 11:51 Go to previous messageGo to next message
lima
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Hi,

Regarding item 3 of these minutes, I would like to clarify what the "1 to 1 relationship" for raw calorimeter hits implies.

Some excerpts from the minutes follow:

> 3) Link between Hits and raw Hits
> a) TrackerHit->TPCHit: need 1 to many relation, cannot
> use LcRelation, because of different types (VTXHit,SITHit,...)
> b) CalorimeterHit->RawHit - need only 1 to 1 relation, could
> in principle use LCRelation - but should be consistent
> with TrackerHit


> 3)
> ...
> proposal is that CalHit.getRawHit() returns a single LCObject
> TrackerHit.getRawHits() returns a vector of LCObjects.


Does this mean that a LCRelation keeps track of one and only one RawCalorimeterHit associated with a SimCalorimeterHit? If so, this design does not allow the implementation of crosstalks for adjacent cells. Can we change this design? We were planning to implement crosstalk in our digitization software.

Thanks,
Guilherme
Re: Minutes of Meeting 2004-09-14 [message #153 is a reply to message #151] Wed, 17 November 2004 00:59 Go to previous messageGo to next message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Hi Guilherme,

If you use the LCRelation to link SimCalorimeterHit and RawCalorimeterHit you are free to store n-m relationships, if needed even with one weight per relation.
So there should be no problem to implement crosstalk in that digitization step. The CalorimeterHit in turn has a 1-1 relationship to RawCalorimeterHit. It is intended to serve as
a common input format to reconstruction and analysis where esentially the amplitude has been calibrated wrt. the raw hit:

 SimCalorimeterHit <N-M> RawCalorimeterHit  <1-1> CalorimeterHit
  [ geant hit ]      |     [ digitized ]      |     [calibrated]
                     |                        | 
                 LCRelation                direct (getRawHit)


-Frank.
Re: Minutes of Meeting 2004-09-14 [message #155 is a reply to message #153] Wed, 17 November 2004 02:28 Go to previous messageGo to next message
lima
Messages: 47
Registered: May 2004
Location: DeKalb, IL, USA
Hi Frank,

Thanks for your answer. Now I would like to understand how to use/store the LCRelation objects. Could you point me to some examples?

Thanks,
Guilherme
Re: Minutes of Meeting 2004-09-14 [message #156 is a reply to message #155] Thu, 18 November 2004 03:10 Go to previous message
gaede
Messages: 233
Registered: January 2004
Location: DESY, Hamburg
Hi Guilherme,

LCRelations are stored in ordinary LCCollections as any other LCObject. Some example code is in src/cpp/src/EXAMPLE/recjob.cc.
For your case you'd do sth. like:


    LCCollectionVec* calHits = new LCCollectionVec( LCIO::RAWCALORIMETERHIT )  ;



    LCCollectionVec* scRel = new LCCollectionVec(LCIO::LCRELATION ) ;
    scRel->parameters().setValue( "RelationFromType" ,  LCIO::RAWCALORIMETERHIT ) ;
    scRel->parameters().setValue( "RelationToType"   ,  LCIO::SIMCALORIMETERHIT ) ;


    // use collection of existing SimCalorimeterHits
    int nSimHits = simcalHits->getNumberOfElements() ;
    for(int j=0;j<nSimHits;j++){

      RawCalorimeterHitImpl* calHit = new RawCalorimeterHitImpl ;

      SimCalorimeterHit* simcalHit =  dynamic_cast<SimCalorimeterHit*> ( simcalHits->getElementAt(j)  ) ;
       // the cast is only needed to access the SimCalorimeterHit's attributes
       // for the relation you can treat it as LCObject:
       // LCObject* simcalHit = simcalHits->getElementAt(j) ;
     
      // set calHit attributes 
      //  ....


      // add relation
      scRel->addElement( new LCRelationImpl( calHit , simcalHit , 1.0 ) ) ;

      // this assumes 1-1 relation 
      // if you have n-m (e.g. due to crosstalk)
      // you can add as many relations as needed
      // possibly using the weight as (relative) energy            
      // contribution

      calHits->addElement( calHit ) ;
    }
    evt->addCollection( calHits , "CalorimeterHits") ;

    LCFlagImpl relFlag(0) ;
    relFlag.setBit( LCIO::LCREL_WEIGHTED ) ;
    scRel->setFlag( relFlag.getFlag()  ) ;

    evt->addCollection( scRel , "CalorimeterHitsSimRel" ) ;





For reading back the relations there is a convenience class LCRelationNavigator that makes it easier to access the information, example code is also in recjob.cc.
I hope this helps.
Cheers, Frank.
Previous Topic:segfaulting PIDHandler in python
Goto Forum:
  

[ PDF ]

Current Time: Sun Sep 15 21:54:23 Pacific Daylight Time 2019
.:: Contact :: Home ::.

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