Minutes (written by A. Ribon) of the LCG Generator Services monthly
meeting on 28 January 2009 dedicated to HepMC 2.05 .
----------------------- ----------------
People attending in room 32-1-A24 :
- John Apostolakis (JA)
- Gabriele Cosmo (GCO)
- Gloria Corti (GC)
- Andrea Dell'Acqua (AD)
- Lynn Garren (LG)
- Osamu Jinnouchi (OJ)
- Anton Karneyeu (AK)
- Mikhail Kirsanov (MK)
- Pere Mato (PM)
- Alberto Ribon (AR)
- Lars Sonnenschein (LS)
- Zbigniew Was (ZW)
People attending remotely via EVO :
- Andy Buckley (AB)
- Roberto Chierici (RC)
- David Grellscheid (DG)
- Judith Katzy (JK)
- Leif Lonnblad (LL)
- James Monk (JM)
- Torbjorn Sjostrand (TS)
=====================================================================
AR presented few introductory slides, showing which versions of HepMC
the experiments are currently using, and the planning to arrive to
the HepMC 2.05 release.
Additional comments to the slides:
---------------------------------
AR reported that the experiments (ATLAS, CMS, and LHCb) will continue
to use HepMC 2.03.09, at least for the first part of the year.
It is likely that when they move to a newer version, they will
go directly to 2.05, skipping 2.04.
=====================================================================
LG presented the collected requests for HepMC 2.05, and a proposal
to address them.
Additional comments to the slides:
---------------------------------
o slide #4 (subjet: HepPDT)
========
LG proposed to add a link to HepPDT in the main GENSER web page
(however, like HepMC, HepPDT will continue to stay outside the
MCGenerators/ subdirectory).
Decision:
--------
The proposal is accepted.
o slides #7 and #8 (subject: Status code)
================
JK commented that ATLAS is using status code 2 in several
places, therefore it would require a lot of work to change it.
GC confirmed that also LHCb is using status code 2 heavily,
and therefore changing it would be a problem.
AR reported that also CMS is using status code 2.
JA commented that Geant4 does not use the status code:
HepMC is not used directly by Geant4, but it is available
as interface under the user control.
AB commented that there is confusion on the meaning of
status code 2. For example, in Pythia it indicates a
physical particle that has decayed. In Herwig++ it indicates
anything that is not final (i.e. status code 1).
He suggested that we should find an agreement on a common
definition of status code 2, valid for all generators.
ZW suggested to keep open the possibility to add an extra
parameter to the proposed new methods, in such a way to
distinguish between different event generators.
DG suggested to adopt a common definition, independent of
which event generator is used, for the status code 2:
a physical particle that has decayed.
TS commented that by maintaining the equivalence of status
codes 11-200 to status 0, and using status code 2 to indicate
a physical particle that has decayed, users loose some
important piece of information on the (generator-specific)
history of the decayed physical particles.
This information would be essential for the MC authors to
understand in detail what happened in the event, in order
to help the experimentalists in their analyses.
One example is when you trace the history of b production.
AD commented that he prefers the method name "is_undecayed"
instead of "is_stable" or "is_final".
Decision:
--------
The proposal of having the new status code 4 for a beam
particle is accepted.
The proposal of considering status codes in the range 11-200
as equivalent to status code 2, instead of 0, is rejected.
The status code 2 should be used only for physical particles
that have been decayed.
The following new methods should be included:
a) bool GenParticle::is_undecayed()
which returns true only if status code is 1 ;
b) bool GenParticle::has_decayed()
which returns true only if status code is 2 ;
c) bool GenParticle::is_beam_particle()
which returns true only if status code is 4 .
Users are kindly invited to use these methods instead of
checking directly the status code value.
o slide #9 (subject: Barcodes)
========
AR commented that the example shown in this slide
(i.e. MCTruthManager) is taken from an extended example
in Geant4, created few years ago by W. Pokorski, to show
how the "MC-truth" information could be treated using
barcodes. Experiments are using barcodes in a similar way
but not necessarily in exactly the same way.
GC said that LHCb is using exactly this approach.
AD said that ATLAS is using a more involved approach.
AB explained that the reason for requiring that the method
suggest_barcode()
becomes a protected function is motivated by the fact that
many people got confused about the meaning and usage of
barcodes, so he thinks that barcode should not be (ab)used
by the users.
He suggested we might consider adding a specific extra integer
flag to be used for the extra information that the barcode is
currently being abused for, otherwise the "abuse" can never
be ended, because there is no other place to put the information.
AD and GC said that barcodes are used heavily in the
experiments to store "MC-truth" information, so changing
this would have a dramatic impact.
LG said that the usage of barcodes should be clearly
documented so that users do not get confused.
AR commented that the use of barcodes, originally introduced
for persistency reasons (to have a unique identifier for
each particle and vertex in an event), have been later on
used to store extra information, and although this could
appear now as a bad choice, it is heavily used by the
experiments since few years, therefore it is practically
impossible to go back and change anything.
AD replied that the choice of using barcodes to store extra
information is reasonable and acceptable because it satisfies
the only assumption behind barcodes, i.e. to be unique
identifiers in each event.
Decision:
--------
The proposal to make suggest_barcode() a protected function
is rejected.
The documentation on barcodes should be improved with a
clear explanation of their use to store "MC-truth" information.
o slide #10 (subject: Vectors)
=========
LG proposed to remove the two methods:
FourVector::mag()
ThreeVector::mag()
DG said that HepMC should be a pure storage of components,
without providing any additional functionality (which, if
needed, should be provided by an external vector package).
Therefore, not only the above two methods should be removed,
but all the other non-accessor vector methods should be
removed (or at least they should become protected
or private methods, not accessible in the public interface).
See below for the full list of methods.
JK, AD said that ATLAS is using some of these methods, but
it should be relatively easy to identify and replace them
when ATLAS will move to HepMC 2.05, so they do not disagree
on DG's proposal. However, they would like to look more
carefully on the ATLAS code to confirm this.
Decision:
--------
Remove from HepMC the two methods:
FourVector::mag()
ThreeVector::mag()
and consider removing the following methods:
FourVector::rho()
FourVector::m()
FourVector::m2()
FourVector::perp2()
FourVector::perp()
FourVector::theta()
FourVector::phi()
FourVector::rho()
FourVector::pseudoRapidity()
FourVector::eta()
ThreeVector::phi()
ThreeVector::theta()
ThreeVector::r()
ThreeVector::setPhi()
ThreeVector::setTheta()
ThreeVector::perp2()
ThreeVector::perp()
This decision will become effective only if in the next
couple of weeks no objections emerge.
o slide #11 (subject: HepMC_CLHEP20)
=========
Decision:
--------
The proposal to remove HepMC_CLHEP20.h is accepted.
o slide #12 (subject: Cross section)
=========
AB commented that Rivet needs to have the cross-section
information on an event-by-event basis.
OJ said that ATLAS does not want to have this extra information
because there are already too many sources of cross-sections
(LO, NLO, calculated by whom?) and the users can get confused.
DG replied that this extra information can always be ignored.
LG asked whether it is possible to use two streams instead of one,
so to put the cross-section information in a separate stream.
AB replied that it is not clear if and how this would work.
GC proposed another solution: put this extra information
in a new class, which is then accessible via a pointer
(similar to the way the HeavyIon information is treated),
so that the users who are not interested in this extra
information can set a null pointer.
DG replied that this solution seems over-engineering.
He proposed a simpler solution: add these two extra numbers
(cross section and its estimated error) in the ascii file,
but without being accessible by methods, so that this
information is somehow hidden.
GC replied that experiments are reading not ascii files but
POOL files so these two extra numbers will be picked up from
the dictionary...
ZW commented that the cross-section information is a property
of the run, i.e. of all the event generated, not of a single
event. So it does not make sense to put this information in
GenEvent: it should be in a global class.
Everybody agrees.
Decision:
--------
The cross section information is a global property of the
run that should be stored in a new "GenRun" class
(not in GenEvent as in the proposal).
The solution must find a way to interleave GenRun information
with GenEvent information in the ascii I/O, if its presence
is requested. Suggestions are welcome.
o slide #13 (subject: Iterators)
=========
LG proposed to move the iterators that are now inner classes
within GenEvent and GenVertex out of these. The main reason
would be that the code becomes easier to read; furthermore,
the code would be easier to parse by some tools, like SWIG.
PM asked whether this changed is exactly backward compatible,
or if it needs some typedefs to allow a sub-type to become a
type...
AB replied that he expects that the change is perfectly
backward compatible, simply by moving the iterators out of
the classes where they are embedded.
Decision:
--------
The proposed change is accepted.
o slide #14 (subject: IO_Ascii)
=========
Decision:
--------
The proposal to remove IO_Ascii is accepted.
o slide #15 (subject: ascii output precision)
=========
Decision:
--------
The proposal to allow variable ascii precision is accepted.
o slide #16 (subject: standard stream IO)
=========
Decision:
--------
The prposal to enable standard stream IO is accepted.
o slides #17, #18, #19 (subject: NaN in input)
====================
Decision:
--------
The proposal to handle NaN encountered in ascii input
is accepted.
o slide #20 (subject: defs.h)
=========
LL and LG had an exchange of emails after the meeting,
and they agreed to put the new #defines in a new header
file, HepMCDefs.h, instead of defs.h (the latter contains
generic macros, such as PACKAGE, that can cause confusion
if picked up outside of HepMC).
Decision:
--------
The proposal to add some #defines to HepMCDefs.h is accepted.
o slide #21 (subject: going forward)
=========
LG said that given the intention of the experiments to
keep using HepMC 2.03 instead of moving to 2.04, she
will keep maintaining only the former.
Decision:
--------
Bug fix releases will continue in the 2.03 branch, and
eventually in the new 2.05, not in 2.04.
=====================================================================
There are minutes attached to this event.
Show them.
