Minutes of the LCG Generators Services meeting held on 03.02.2010 Present: Lynn Garren (LG), Witek Pokorski (WP), Alberto Ribon (AR), Gabriele Cosmo (GC), Pere Mato (PM), Mikhail Kirsanov (MK) Present on EVO: Andy Buckley (AB), Fabio Cossutti (FC), David Grellscheid (DG), Albert Knutsson (AK), Torbjorn Sjostrand (TS) This was a special meeting devoted to HepMC release planning. Lynn Garren presented the new features which are under discussion (slides: http://indico.cern.ch/conferenceDisplay.py?confId=80889). Proposal 1: Named weights AB asked about the name of the method 'search' (page 8). Is it the right name for this method. AB comment offline: I would prefer a name with a more explicit logical name, such as bool has_key() or has_name(). David Grellscheid mentioned privately that if the idea is to mimic an std::map's behaviour, then it should look like an std::map: this might be too hard to implement, e.g. returning the right sort of iterators for the std::map::find would be a pain with little real-world gain. So I personally think that sticking with changing the name to something like has_name() would be enough, without being confusing. AB question offline: What is the proposal for storing (and re-reading) the weight names in the ASCII format? LG comment offline: I am presuming that the weight names will NOT contain spaces. If they do not contain spaces, then it is trivial to write them out, If they are allowed to contain spaces, then HepMC will need to delineate the strings using some other character - perhaps brackets or parentheses. Here is where feed back from the users will be very useful. How long do you expect the names to be and should they be allowed to contain spaces? Right now, ASCII I/O simply adds yet another line to the event header: N ... I decided to write the size (number of entries) of the weight container on the named weight line even though it duplicates the information on the event line. The two sizes must agree. If they don't, then the event has corrupt information. It would also be possible to write one string per line, but I would rather not do that unless the names will be very long. AB comment offline: This sounds fine to me, but I think assuming that spaces would not be needed is rather dangerous. The obvious thing (to me) would be to delimit the names with quotation marks, i.e. N 41 "PDF 0" "PDF +1" "PDF -1" "PDF +2" ... This is a little harder to parse than some other schemes, but has the benefit of being obvious to the user and in keeping with lots of other ASCII formats. Whether to also accept single quote character delimiting, etc. would need to be decided: might be best to ban it, so that it can be used as an apostrophe in names. Obviously the quote characters would need to be banned from the names, assuming that you don't want to get into the world of recursive character escapes! I think quote-mark characters can fairly safely be assumed not to be commonly wanted in names, unlike brackets or parentheses: I can easily imagine someone wanting to name PDF error members as CTEQ66[3] or CTEQ66(3). Otherwise proposal accepted. Proposal 2: New iterators AB: certainly useful. A few points to be discussed. AB: could we have the const equivalent for the GenVertex iterators? LG: Probably yes. AB: The names should probably be re-though. Maybe something like ConstGenParticleRange? AB: Could we have something like genevent.particles() to return the iterator (range)? And similar for genevent.vertices(), genvertex.particles_in(const Relation&=relatives), genvertex.particles_out(const Relation&=relatives). Comment by LG after the meeting: the names could be something like ConstGenEventParticleRange (similar to AB proposal, but a bit longer) Comment from AB to the above proposal by LG: This would be needed if different iterator types are needed to iterate over the particles via a GenEvent or a GenVertex. In general this shouldn't need to be the case, but I don't know the status of the nested iterator classes... so if a single interator range type can be used for iterating on particles from GenEvent and GenVertex then I think it should just be called a (Const)GenParticleRange since it isn't tied to a GenEvent. Comment from LG to the above point: The GenVertex and GenEvent iterators are different. The GenEvent iterators iterate over the entire event and do not accept an IteratorRange. They are completely separate from the GenVertex iterators which accept the IteratorRange. This makes sense (to me at least) when you think about use cases. Conclusion: Lynn will put it into the beta release. Proposal 3: ASCII I/O and heavy ion and pdf info lines Accepted. Proposal 4: Binary I/O Not everybody convinced that it is needed at all, so the proposal is to have it as a completely separate package. Proposal 5: Remove deprecated classes Accepted. Proposal 6: GenParticle polarisation AB: the idea to store the pointer will not be accepted by the experiments. We go the other way with 'is_set' flag. Lynn will put it into the beta release. Further comment from AB on Savannah: I think there should be a set_undefined(), yes... although I don't think it needs a bool argument. For starters, it poses a bit of a confusing double negative if you can say that something is "not undefined"! IMO, the default value should be (0,0) with the m_defined flag set to false. If set(theta, phi) is called, then clearly those values are set and m_defined == true. If set_undefined() is called, then it goes back to the default setting, including the (theta,phi) == (0,0) ... this latter because it gives a definite value to show up in plots and highlight a bug if the information is being misused. Proposal 7: Reduce HepMC size WP: this should be rather an external tool and not part (a method) of HepMC Comment from AB offline: The idea was to provide a standard function (not a method, note) which implements HepMC's own definition of which event record entries are for physics analysis (etc.) use and which are internal generator documentation details. I would never expect it to be used before storing events -- as I mentioned, the generator-specifics are essential for debugging -- but as a generally useful truth analysis concept which isn't entirely trivial to write, I thought it might be useful to have the function available in HepMC itself if users should need/want it. Perhaps tools like this (and the SWIG interface) could be made available from the HepMC web page, if they shouldn't go in the package itself? Comment from WP concerning the above: I am still not convinced if that should be part of 'core' HepMC, but a function (and not a method) sounds certainly much better to me. On the other hand, we start adding functions to HepMC, where do we stop…? If this, however, is supported by a number of people, we can give it a try in the next beta release. Proposal 8: Pythia & Herwig wrappers Consulted with the authors and accepted. Proposal 9: Installed location of examples Accepted. Final conclusion: Lynn is going to prepare the beta release including all the proposed changes.