To all MINOS simulators, Greetings: A stand-alone version of the NEUGEN neutrino interaction event generator is now available from the MINOS CVS repository. This generator is the one extracted by Rob Edgecock from the Soudan II Monte Carlo. Assuming that you are on the list of users with access to the CVS repository, you can check out the module "neugen". The distribution includes the necessary Makefiles and instructions in the README file concerning definitions of some environment variables. I have tested the program on both bigbang (ALPHA/osf) and mimosa (HP). A successful executable file was created on both platforms, and the output "hepevt.dat" file was successfully read into GMINOS. This should be considered a very preliminary version of the program. In order to make it available quickly, Rob left the internal BOS structure intact. This means that the code distribution includes the necessary BOS routines in their own subdirectory. There are also several unresolved issues concerning the user interface with the program. For now, Rob has defined reasonable default values for what will become user-adjustable parameters. The relevant portions of Rob's "release notes" are included below. I have added a few minor adjustments to Rob's stand-alone driver routine, mc_main.F. My additions: (1) allow the user to input the requested number of events in the one-line formatted file "user_param.dat"; (2) open and fill the unformatted binary file "hepevt.dat", which can serve as input to GMINOS in its current incarnation; (3) set the interaction vertex at (0,0,0), since the gukine routine of GMINOS (as it now exists) expects this to be the case. Other than those changes, I have left mc_main.F as Rob wrote it. He created it in order to test the stand-alone operation of the generator, so the selections of neutrino types, target nuclei, etc. are fairly unsophisticated. Anyone who wishes to use NEUGEN right away should realize that s/he may want to make some changes in her/his personal version of mc_main.F. I also made a minor change in the GMINOS gukine routine to allow it to properly read in all particles that GEANT needs to deal with. Those of you who have GMINOS already checked out will want to update gukine. The eventual goal for this program, of course, is to integrate it with GMINOS and with the beam code(s). Robert Hatcher and I plan to begin work next week to define and encode the interface between GMINOS and NEUGEN. Any others of you who are also interested in participating in this effort are encouraged to contact either Robert or me. I'm looking forward to hearing from others among you with code to share. Let's stock the repository! Lynn *************************************************************************** Excerpts from Rob's e-mail release notes on NEUGEN: *************************************************************************** A few things should be noted: (1) As you will have guessed by now, this version still uses BOS internally as to take it out is a non-trivial amount of work and would have delayed the release of the code. The bos subdirectory contains the subset of the Soudan BOS code required to link the generator. BOS will be removed in a later release. (2) As I've mentioned before, there are many options in the generator which have had to be set to defaults because a way of allowing users to select such options has not been defined by MINOS. I believe we need to do this asap (via ffread cards, titles, etc?). (3) Also as mentioned before, I believe some study of the Physics of the generator at MINOS energies is required, particularly the cross-sections and the treatment of the hadronic system. Following the removal of a bug that caused it to crash above 70 GeV, the generator will generate neutrinos up to an energy of 120 GeV. (4) In an earlier email, I was a bit optimistic about the nucleii the generator can handle. For the material in the detector, it can only deal with the most common isotope of each element and it only properly handles a subset of the elements with a Z between 1 and 29. The actual materials used in MINOS will have to be specified and any missing nucleii can be 'trivially' added. (5) The generator talks to the rest of the world via two common blocks, as specified in [minosmc.neugen.new.inc]neucom.inc. These are basically a copy of the ESETs defined by Robert. However, please note there are a couple of changes: o IBOSON has been replaced by IRESONANCE. This is the entity that produces the hadronic final state in the generator. IRESONANCE = 0 for quasi-elastic scattering, 1-18 for resonance production and >20 for inelastic scattering. o IACTION now only takes two values: 0=NC and 1=CC. o SIGMA depends on IRESONANCE. For inelastic scattering, it is d(sigma)/dxdy, while for QE and resonance production, it is d(sigma)/dqds, where qds = (1 -q**2/M**2)**-3 (??). o The variables that the generator assumes are filled when called are marked in neucom. It fills everything else in the neukin common except for p4shw and emfrac, as I believe this can only be done after Geant has done it's stuff (6) The stdhep common is filled as follows: o initial state particles: these are always a neutrino, the target nucleus and the target nucleon within the nucleus. They have an isthep of 3. o intermediate state: these usually consists of the recoil nucleus, a lepton and some "resonance". They have an isthep of 0. If the lepton is a tau, it is decayed by tauola. Otherwise it is left to Geant. The recoil nucleus is also left to Geant. The resonance is decayed. The particles from this decay may be rescattered within the nucleus and hence have an isthep of 2 and some daughters. The true final state particles from this will have an isthep of 1 and no daughters. So, to summarise, the particles that need to be dealt with by Geant will have no duaghters and an isthep of 0 or 1! o idhep: for 'normal' particles, the PDG number is used as required. However, nucleii and 'resonances' don't have a PDG number. Geant, on the other hand, does have a number for certain selected nucleii. So, what I have done is take to the Geant number of the nucleii closest to the actual and add 100000. e.g. for Iron55: Geant doesn't have a number for this, but does for Iron56, i.e. 87. Thus, the idhep stored is 100087, although the remaining parameters will be for an Iron55 nucleus. The idhep for the resonance will be in the range 1000200 to 1000255, but this is essentially stored for completeness only. o VHEP(4) is not filled (or rather, it always has 0) (7) All the commons and flags in the generator have been converted to use cpp. There is one main flag, DEBUG_PRINT, which is obvious, I hope! (8) Random numbers: on first call, the generator will initialise its own random numbers. This may not be optimal, depending on what happens in beam code. (9) Finally, for those in the know, the rsq_xsects.dat file has been removed and the cross-sections that used to be stored in it are now calculated and stored on first call. This it to make the code more transportable (I hope!) ************************************************************************ Rob's comments on his problems with making the code work on UNIX ************************************************************************ For those interested, there were three main problems getting the code working: (1) many variables had to be saved, mainly in the cross-section routines (rsq*); (2) the BDPART block data didn't work as setup and had to be changed; (3) protections had to be added to tauola because the units it works in lead to very small numbers (interestingly, after adding the protections I noticed that Aleph had had to do the same in their version tauola!). Questions or comments are welcome. cheers........Rob **************************************************************************