Print

---

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.

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
 

 
  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]
========================