LCG Generator Services project planning meeting

Friday 23 May 2008, 09:30 → 12:30 Europe/Zurich

32/1-A24 (CERN)

EVO video-conference: community="WLCG", title="Generator Services project planning". Telephone conference: title="Generator Services project planning", organized by "A.Ribon".

09:30 → 10:30 Report and planning

Speaker: Alberto Ribon (CERN)

Slides genPlan23May08.pdf

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.