 |
 |
Hi Mike, thanks for the reply. > Bob, > > I'd like to hear what Tony has to say. I've been catching the > UnknownParticleID exceptions and handeling the different objects, like > strings, di-quarks, etc. I would propose that we extend the > DefaultParticlePropertyProvider by creating a > PythiaParticlePropertyProvider to handle the Particle ID exceptions that > the Pythia authors choose to make. In the LCD recon. files I used last year, there were a few non-standard oddities that I was happy to catch, for example the ID=123456789 "IDontknowino"! I noticed that the Pythia objects I was catching in v6.154, like strings (ID = 92), had an official code and name in the PDG book. I was also catching "real" particles, e.g. ID=415 (some excited state of a D that may not have been observed, but Pythia at least thinks it should exist -- there are numerous others like that). According to the Pythia manual, the author(s) use the algorithm that was developed for the PDG (with there input) for all particles. However, for a few they disagree about how the rule is applied. Since the PDG codes are (should be) the standard, should we put them (in their entirety) into the DefaultParticlePropertyProvider and put only the differences into a Pythia...? There are about 300 entries in the PythiaParticlePropertyProvider.java I generated from the Pythia code, only a few (I haven't checked which exactly) are different. I have checked a number of the "standard" particles. Another alternative (until someone does the XML version ... I may get to it at some point this year) is to take the Pythia list, prune it of the Pythia specific entries and provide that as the DefaultP... plus provide the PythiaP... in full. Should it have a version number in its name (currently I write it into a comment line)? A method to set the version? Is this making it too complicated? > > I've been working on a PythiaMonteCarloAnalyzer class that handles > reading generated Pythia events and deciphering the production channel > and decays. A base MonteCarloAnalyzer class provides a standard > interface to the generated information. You can find the code off my > SLAC directory at > > http://www.slac.stanford.edu/~ronan/code/lcd/hep.lcd.mc.analysis > > the methods in PythiaMonteCarloAnalyzer that might be of general > interest are: > > HEPLST(ParticleVector pv) - Provides a Pythia-like dump (see Tony's > new PlugIn) > interpretPythiaEvent(LCDEvent event) - Interprets Pythia documentation > and decay chains > I will take a look. > > It seems clear to me that we need to provide 1.) base classes to > handle routine interfacing to the generator information, and 2.) > subclasses for each of the standard generators to handle all the details > and exceptions that are introduced by the different authors. > > Mike > > P.S. There's nothing wrong with writing a FORTRAN program to test your > memory skills, but I wouldn't show it to anyone under 25 years of age. > Please send me a copy of your program and I'll try my hand at converting > it to Java using Native Interfacing to the Pythia common block. I thought I might get some grief for that! I used FORTRAN because Pythia is written in FORTRAN. I could simply copy the blockdata from their code and paste it into a modified version of their own subroutines (which convert internal IDs to PDG). This was the most expeditious way for me that has the least chance of me introducing errors. The compilation is a simple g77 pythnames.f. Future releases of Pythia will remain in FORTRAN for quite a while (though an effort is underway to produce an OO version). In that case, one would need only to repeat the copy, paste recompile, rerun to generate an updated code for JAS. Minimum effort and risk of errors? (Note the question mark). I agree that FORTRAN is an old nasty way to do things. The Pythia code uses IMPLICIT typing for integers (I-N) and reals so gives no warnings if a name typo introduces a variable with some random value. It is possible to to have the arrays in common blocks be single precision in some routines and double in others. Since there is a lot of legacy FORTRAN out there, I would be interested to see how you would handle this kind of task in Java. You have some complex routine/common that has to remain in FORTRAN but you want "foolproof" use of it in OO. Is the Native Interfacing a way of dropping a FORTRAN common block into a Java class? How does it handle notorious blockdata initialisations? I will send the FORTRAN in a separate mail so the rest of the list will not be offended by its presence ;-). Bob -- Robert J. Wilson Professor of Physics Department of Physics Colorado State University Fort Collins, CO 80523 Phone: (970) 491 5033 Fax: (970) 491 7947 Email: [log in to unmask] August 2000 - July 2001: ======================== Institut de Fisica d'Altes Energies Universitat Autonoma de Barcelona E-08193 Bellaterra (Barcelona) SPAIN Phone: (011 34) 93 581.33.22 Fax: (011 34) 93 581.19.38 Email: [log in to unmask] ========================