Minutes (written by A. Ribon) of the LCG Generator Services
planning meeting on 23 May 2008.
-----------
People attending in room 32-1-A24 :
- Paolo Bartalini (PB)
- Jon Butterworth (JB)
- Gabriele Cosmo (GCO)
- Gloria Corti (GC)
- Osamu Jinnouchi (OJ)
- Pere Mato (PM)
- Alberto Ribon (AR)
- Peter Richardson (PR)
- Patrick Robbe (PRO)
- Lars Sonnenschein (LS)
- Zbigniew Was (ZW)
People attending remotely via EVO or telephone
- David Grellscheid (DG)
- Hannes Jung (HJ)
- Judith Katzy (JK)
- Leif Lonnblad (LL)
- Torbjorn Sjostrand (TS)
=====================================================================
AR presented the status of the ongoing activities in the LCG Generator
Services subproject since the last planning meeting (30 November 2007),
and the plan of work for the next 6 months.
Comments to the slides
==================
1) Comments to slide #6 ("Evaluate autotools for a more robust
building of some generators")
a) JB commented that the request of a more robust building mechanism
for GENSER was originated by RIVET users, but it condensates the
request of a much larger group of users, in particular many
Monte Carlo authors and experimentalists who wants to install
the generators in their laptops. In this sense, it should be
considered as an important request coming from a large community.
Furthermore, it can also ease the transition to future supported
platforms, as for instance SLC5.
b) TS commented that it is important to make the transition, from
the current building system of GENSER to a new one based on
autotools, very carefully making sure that everything is properly
tested and working before to abandon the present system.
c) DG commented that autotools should not be used directly on
the Grid, but only to build the libraries that will then be
distributed to the Grid, and therefore there should not be
any problem of relocating the libraries.
d) AR concluded that a meeting to discuss the technical details
of the usage of autotools in GENSER, starting with Pythia6
as concrete first application, has been organized for Tuesday
3rd June, at 15:00. An email will be sent around to advertise it.
Decision : autotools should be carefully evaluated and tested
-------- in GENSER.
-----------------------------------
2) Comments on slide #9 ("Progress report: HepMC")
a) JB commented that the introduction of a new formal way to
discuss and approve changes in major HepMC releases,
starting from 2.04, is a good thing, but it is not enough.
HepMC should also define "Standards", i.e. clear, unambiguous
way to fill information in HepMC.
As an example, the primary vertex should be filled by all
generators.
As another example, introduced in HepMC 2.04, the PdfInfo
should contain the PDF momentum densities x*f(x).
These "Standards", that not necessarily affect the HepMC code,
should be discussed widely between all HepMC users, and once
they have been agreed, they should be clearly specified in
the HepMC documentation.
b) DG added another example where a "Standard" is still needed
in HepMC, namely the format of the HepMC files.
c) AR asked whether these "Standards" should be also enforced
in the code, if possible.
The reply (from PM, JB, and others) was that it depends on
each individual case, and on the complexity that it would
require to implement it, so it should be also a matter of
discussion.
Decision : HepMC should also define "Standards" and include
-------- them clearly in the documentation.
Further discussions on the same slide:
d) DG commented that the new formal way to discuss new HepMC
releases did not work well, in particular for what concerned
the Savannah discussion thread, where some comments where
ignored for several weeks. At the end, a good solution has
emerged, but it took a long time and he hopes that for the
next time we can converge more quickly.
e) JB and PM commented that is one of the role of the coordinator
of the LCG Generator Service project to moderate the
communications between all the parties and making sure that
the discussions converge, rapidly and productively, towards
a common solution.
The hope is that the experience gained for this release
can help to improve for the future.
-----------------------------------
3) Comments on slide #12 ("Milestone overview")
a) AR explained that the delay on installing MC@NLO is due to
the special feature of this generator of not providing any
library. He sees 3 possibilities:
1) Ask the authors to change the structure of the package
in such a way to provide a library.
2) Assign to a GENSER integrator the task to investigate
how to change the structure of the package in such a
way to provide a library, and then propose it to the
authors.
3) Distribute in AFS only the source code, and one example.
The third solution would be the easiest.
b) JK commented that several ATLAS collaborators are requiring
MC@NLO, and it would be nice to have it centrally installed
in GENSER, possibly in a short time scale.
c) PR commented that the MC@NLO authors are working on the
structure of the package, in order to make MC@NLO usable
with Herwig++. Therefore, it could be a good moment to ask
them to provide a library.
Decision : GENSER should install only the source code of the
-------- current version of MC@NLO, plus an example (which
can be used to test it in the supported platforms).
Furthermore, AR should contact the authors to
ask them if they can provide a library for future
versions.
-----------------------------------
4) Comments on slide #15 ("Proposed milestones")
a) JB requested to anticipate, if possible, the date of the
proposed milestones (most of them "20/12/2008") to the
next planning meeting, that is scheduled between the end of
November and beginning of December 2008.
This should facilitate the discussion of what has been
achieved and what needs to be completed.
b) AR agrees and will update the slides moving the milestone dates
to 01/12/2008.
-----------------------------------
Further discussions after the presentation
================================
5) Synchronizing the GENSER libraries with a given HepMC version
a) JK asked what is the GENSER policy with the generator libraries
when a new version of HepMC is released.
ATLAS needs to have all generators consistently built with
the same version of HepMC.
b) AR answered that there is not a real "policy" in GENSER, but
what has been done so far is to use the latest HepMC version
available at the moment that a new version of a generator is
announced, and shortly after installed.
If later, a new version of HepMC appears, the generators
are not re-built using this more recent version of HepMC.
However, starting from a different request (by the Rivet
community, and, independently, by the DESY MC group) of
providing a way to build the whole of GENSER from scratch,
it is in progress the study of a mechanism that allows to
"bootstrap" GENSER with a specific version of HepMC (and
other common packages, like LHAPDF and ROOT).
This will also be discussed at the technical meeting, already
memtioned above (regarding autotools), scheduled for June 3rd.
c) DG commented that the current versioning convention used by
GENSER and HepMC does not allow to distinguish between
versions of the libraries that are compatible (because
only bug fixes have been included) and incompatible
(because of changes in the interfaces).
d) JB agreed with the comment of DG, and said that we should
discuss this argument in the meeting on June 3rd.
e) PM reported that the problem of synchronizing to the same
HepMC version between ATLAS and LHCb already emerged,
and as soon as LHCb will complete the transition to HepMC-2,
it would be possible to build consistently all GENSER
libraries with a common HepMC version.
Decision : The synchronization of GENSER libraries with a given
-------- HepMC version should be kept in mind and discussed
further, starting from the meeting on June 3rd.
-----------------------------------
6) Explaining the structure and usage of the Event Record
a) ZW commented that it could be sometimes difficult, especially
for students and young postdocs who are not familiar with
simulations, to understand how the structure of the
Event Record in HepMC is organized and how to use correctly
the information it provides. Furthermore, the differences
between various generators make things even more complicated.
Therefore, the HepMC documentation should be improved
in order to be useful and instructive also for non-experts.
b) JB agrees and added that it is one of the responsabilities
of the generator coordinators of each experiment to educate
their collaborators to a proper usage of Monte Carlo tools,
including the Event Record.
-----------------------------------
Feedback after the meeting
=====================
7) Particle code usage in HepMC for PDFs
TS pointed out that users should always use PDG codes in HepMC.
including for PDFs.
In particular, PDG code 21 should be used for the gluon PDF.
-----------------------------------
8) Particle status code
For the coming HepMC release 2.04, the particle status code
remains unchanged, i.e. the HEPEVT convention should be
followed.
However, discussions on how to improve the status code have
already started between Monte Carlo authors, and it will be
one of the major topic for next year's HepMC release 2.05.
TS reported that there seems to be already a consensus that
the range 11 - 200, that is already reserved for specific
event-generator information, should be changed from being
equivalent to a null entry to being equivalent to status 2,
i.e. objects already decayed.
In practice, this means that users should be prepared to
test for status 1 or not-1 rather than 1 or 2.