Linear Collider Forum



Home » Software Tools » LCIO » Meeting Minutes
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 previous 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
===============================================

 
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 Nov 14 04:57:49 Pacific Standard Time 2018
.:: Contact :: Home ::.

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