Choose timezone
Your profile timezone:
LCG Generator Services monthly meeting
→
Europe/Zurich
32/1-A24 (CERN)
Description
LCG Generator Services monthly meeting.
EVO video-conference: community="WLCG", title="LCG Generator Services".
Telephone conference: title="LCG Generator Services", organized by "A.Ribon".
Minutes (written by A. Ribon) of the LCG Generator Services monthly
meeting on 5 March 2008 dedicated to HepMC releases .
------------ --------------
People attending in room 32-1-A24 :
- Gabriele Cosmo (GCO)
- Gloria Corti (GC)
- Lynn Garren (LG)
- Osamu Jinnouchi (OJ)
- Pere Mato (PM)
- Alexandre Ryabov (ARY)
- Alberto Ribon (AR)
- Peter Richardson (PR)
- Lars Sonnenschein (LS)
People attending remotely via EVO :
- Andy Buckley (AB)
- Jon Butterworth (JB)
- Nadia Davidson (ND)
- David Grellscheid (DG)
- Mikhail Kirsanov (MK)
- Frank Krauss (FK)
- Hannes Jung (HJ)
- Leif Lonnblad (LL)
- James Monk (JM)
- Tomasz Przedzinski (TP)
- Torbjorn Sjostrand (TS)
- Zbigniew Was (ZW)
=====================================================================
AR presented the proposal of how to handle HepMC releases from now on.
Additional comments to the slides:
---------------------------------
PM suggested to have a pre-release (beta-release) available for
testing few weeks before the official release, to get user feedback.
Decision:
--------
The proposal of AR has been approved, with the addition of a
pre-release as suggested by PM.
=====================================================================
LG presented a status report of HepMC, a set of issues and requests
from users, and some proposal to address them in the next release.
Additional comments to the slides:
---------------------------------
1) LG said that a number of old HepMC versions, which have likely
never been used by anyone, could be deleted, and ask to the
audience how to deal with those.
TS (after the meeting via email because of problems with EVO)
also would like to have older Pythia8 versions 095, 090 and 080
cleaned up, which have likely never been used by anyone.
PM said that we should not worry about AFS space.
LG and DG reply that cleaning up older versions is not done mainly
for freeing disk space, but for avoiding confusion and a
proliferation of deprecated versions that users might use
by mistake.
GC and PM said that removing older versions, even if buggy, should
be done extremely carefully, because some users could have used
them in the past but then have the need to generate some extra
samples with the same version for further studies.
PM said that this problem is not specific to MC Generators, but
common to any package installed in the AFS external area, and so
a similar solution should be followed.
Decision:
--------
Adopt the same solution as for other external packages, namely
the following.
Inform the users via email of the list of old, deprecated versions,
and ask whether these packages are still needed.
Wait for a couple of weeks for feedback.
If the reply said that some of these versions are still needed,
then these versions should be kept.
If the reply said that some of these versions are not needed,
or no reply at all has been received, then these versions should
be renamed as "old" or "deprecated" and an email should be sent
around informing the users about the renaming and telling also
that these versions will be removed in few months, unless there
is an explicit request to support them.
After few months, if no user request them, send a last email
informing that these versions will be deleted on a specified date.
Finally, at the specified deadline, these versions can be removed.
2) LG proposed to reduce some ascii files in test subdirectory.
Decision:
--------
OK
3) LG proposed to add to SimpleVector a new templated method,
convertTo() that will construct a user vector from a FourVector.
FK pointed out that such a method assumed a specific ordering
between its component, i.e. (px, py, pz, E) and (x, y, z, t),
whereas other vector classes may have a different convention,
i.e. (E, px, py, pz) and (t, x, y, z). In these cases, the
usage of such a method could produce, silently, wrong results.
So, to avoid these kind of mistakes, it is safer not to introduce
this new method.
Decision:
--------
Leave the HepMC vector classes as they are now, without adding
the method convertTo().
4) LG proposed to revise the IO_HERWIG class.
PR said that it is safer to avoid to modify this class, because
Herwig Fortran is stable and this revision could introduce new bugs.
Better to modify this class only if really needed, that is when a
bug will eventually show up.
Decision:
--------
No revision of the IO_HERWIG class.
5) LG reported that Pythia8 seems sometimes creating GenVertex objects
without particles attached, and this situation is not foreseen for
a HepMC vertex.
After the meeting, LG, MK and TS has investigated the problem,
and it is now fixed in Pythia 8.107 .
6) LG proposed to add two new methods in IO_HEPEVT class for dealing
with beam particles.
Decision:
--------
These new methods have been approved.
7) LG proposed few solutions for the lack of units in HepMC.
DG commented that it would be useful to have at least a string,
in the header of a HepMC file, which specifies the energy unit
("MeV" or "GeV") used for all the events in the file.
PM is worried that this string information is not enough,
otherwise the user code should deal separately the two cases
("MeV" as energy unit, or "GeV").
OJ and GC pointed out that ATLAS and LHCb use consistently MeV
everywhere, so in particular they take care of converting the
GeV results from the generators into MeV before writing HepMC
on files, or passing them to Geant4.
PR and TS (via email) pointed out that both Herwig++ and Pythia8
allow the user to choose between MeV and GeV units when writing
out HepMC.
TS (via email) agrees with DG that each event file should contain
one line with info on the units used to store events. If the only
disagreement is GeV vs. MeV then we only need to use a bool.
In a run this could then be set or get with suitable methods.
For output, one could imagine methods that return answers in
specified units, e.g. if you now have a method px() you could
replace that by three:
* px() returns the native format, whatever that is;
* pxInGeV() converts where necessary to ensure GeV units;
* pxInMeV() converts where necessary to ensure MeV units;
Alternatively you could keep one method but supply an optional
argument,
* = 0 = default: no conversion;
* > 0 : always GeV;
* < 0 : always MeV.
The discussion went on for a while, with different positions,
but without a clear consensus.
After the meeting, the discussion continued in the HepMC's Savannah
(see "#bug 32710" in the "Bugs" group). It has been pointed out
here by AB and PM that the issues of units in HepMC does not apply
only to the persistent format.
Decision:
--------
LG has prepared a proposal to address the unit issue in HepMC,
which tries to take into account, as much as possible, the
various opinions.
See http://lcgapp.cern.ch/project/simu/HepMC/20400/ .
8) AR proposed to drop the HepMC support for SLC3 g++ 3.2.3 , because
it is no longer used by the LHC experiments.
Decision:
--------
Approved.
9) LG proposed to drop the HepMC support for Windows VC 7.1 platform,
because it is based on a very old compiler, and not ANSI compliant,
and eventually replace it with mingw.
GC said that LHCb is still using Windows VC 7.1 and therefore its
support must continue. However, for the future, it could be that
LHCb will move to Windows VC 9, which is newer and ANSI compliant,
so it should be easier to maintain.
Decision:
--------
Continue to support Windows VC 7.1 .
Support for mingw is not required.
10) LG is asking whether any compiler name should be allowed for
building HepMC, because this might bring complications.
DG and AB said that autotools can and should be used without
enforcing the name of the compiler. Eventually, one could treat
the case of Windows VC 7.1 as a special, exceptional one.
Decision:
--------
Explore the possibility of allowing any compiler name when
building HepMC.
DG and AB agreed to give Lynn some suggestions and help.
11) LG is asking which version number should be used for the next
version of HepMC, 2.03.06 or 2.04.00 ?
Decision:
--------
Given that the new version will have some additions/changes
which are not pure bug-fixes the new version of HepMC should
be 2.04.00 .
=====================================================================
LS presented few slides with some comments and questions on HepMC.
Additional comments to the slides:
---------------------------------
i) Do we need/want a freestanding method (within HepMC) to
repair/complete HEPEVT mother/daughter relations?
Decision:
--------
For the time being, such a method is not required.
(We keep it as a possibility for future HepMC releases,
in the case we need.)
ii) Do we need a HepMC dictionary conversion (outside HepMC)
given that older Root files written with HepMC 1 contain
CLHEP vectors?
PM pointed out that this is an important issue, related
also to the Root schema evolution, and should be discussed
in detail with Root experts.
Decision:
--------
Nothing specific to HepMC is required.
=====================================================================
Further discussions:
a) JM observed that sometimes there is a difference between
the HepMC version that an experiment is using and the HepMC
version used by Genser to install a generator. This could
create incompatibilities and therefore force the experiment
to build its own version of the generator, instead of using
the one provided by Genser.
PM replied that if HepMC manages to follow the proposed
frequency of new releases (excluding here patches), of not
more than one (ideally) or two (max) per year, then it should
become easier to synchronize the usage of the same HepMC version
between Genser and the LHC experiments.
b) Several people (PR, JB, TS (via email)), in different moments
during the meeting, made some comments regarding the integer
status code in the class GenParticle in HepMC.
Here is a short summary of some of these comments, as far as
I can remember:
PR is asking to the users whether they would like that
Herwig++ status codes are the same as in HEPEVT.
No clear answer.
PR said that some users have complained that Herwig++ status
codes are different from Pythia8.
PR warns users to avoid to use the status codes to get
unphysical information.
TS (via email) said that Pythia8 has a wide selection of
particle status codes, that provides much information for
experts. However, where required, he will throw away such
information and replace it with the standard codes.
He thinks that it would have been great if both codes were
stored, the generator-specific ones and the extremely crude
HepMC internal ones.
TS (via email) said that another related issue that has not
been discussed is the following: what is the format for
parton ID codes for parton-density information?
TS was assuming that gluons would be represented by 21, like
they are in the event record, but MK said that some frameworks
expect g = 0. TS recall this from the old Fortran days, when
people often created a vector(-5:5) to hold everything from
bbar to b with g in slot 0, but had not realized that this
might still be living on.
So TS believes this is an issue that should be clarified, by
being brought to the attention of everybody.
LG (via email, after the meeting) said that HepMC is a container:
it has no requirements about what the status codes might be.
HepMC::GenEvent simply has an int data member for status code
information.
In the HepMC manual there is the following prescription on the
status code:
Status codes are as defined for HEPEVT:
0 null entry
1 existing entry - not decayed or fragmented,
represents the final state as given by the generator
2 decayed or fragmented entry
3 documentation line
4-10 undefined, reserved for future standards
11-200 at the disposal of each model builders -
equivalent to a null line
201- at the disposal of the user, in particular for event
tracking in the detector.
MK (via email, after the meeting) said that CMS is indeed using
0 as code for gluons.
Decision
--------
No changes in HepMC are required.
However, users are kindly invited to follow these conventions
(already specified in the HepMC manual):
- PDG particle codes
(in particular, the old usage of code 0 for gluons is
deprecated!)
- HEPEVT status codes.
c) An important point that needs to be clarified has been brought
up by TS (via email) after the meeting: the PDF information in HepMC.
In the HepMC::GenEvent class there is the member function pdf_info()
which returns a pointer to a PdfInfo object.
The class HepMC::PdfInfo has the two member functions: pdf1() and
pdf2(), which are meant to return, as a double, the "pdf" of the
first parton ("beam side") and second parton ("target side),
respectively.
The problem is that it is NOT specified (in the class or in
the HepMC documentation) whether these functions should
represent "f(x)" or "x*f(x)" .
ATLAS has required to add in the HepMC::PdfInfo class the integer
ID that identifies uniquely the PDF set in LHAPDF.
Decision:
--------
The PDF information in HepMC should represent x*f(x)
(this choice is motivated by the convenience of keeping the same
convention as in LHAPDF).
This does not require any change of code in HepMC, but this
convention should be clearly documented (in both the HepMC
manual and as comments in the HepMC::PdfInfo class).
Furthermore, two integer data members (with corresponding
public get/set methods) should be added to the HepMC::PdfInfo
class to store the LHAPDF set ID for Beam 1 and Beam 2.
d) TS (via email after the meeting) would like to inform the users
that in future Pythia 8 releases only HepMC v2 will be supported.
=====================================================================
There are minutes attached to this event.
Show them.
