uv4.71
Release  '98/03/21
Bug fix
	If the KEminObs is very small, one might encounter a
 case with the zero divide in cadjm.f.  This was corrected.
 This correction is important if the library is used by
Epics to simulate showers as low as 100 keV. 

 The difference in the K0 and K0_bar collisions are taken into
account seriously in the Lund/NewLund/Nucrin routines.
However, low energy K0's  almost all decay in  the atmosphere,
it is expected that we cannot observe the difference in the 
results.  The difference in their decay has been treated
correctly so far.

uv4.70
Release  '98/03/14
Bug fix.
  1) Related to all users;
    a) There is a part in Nucrin (aado.f) that
       results in the zero divide. This was corrected.
    b) There is a part in Nucrin (aadn.f) which leads to
       semi infinite loop (To generate one random variable with
       the exp distribution, one may need more than a minute or 
       much more depending on  how small a uniform random number
       produced is.  Nucrin used a sophisticated method (a la
       Neymann; see rexpC in aadn.f). This was changed to use
       log(uniform random number).
    c) One dimensional calculation sometimes went into infinite
       loop, especially for a large zenith angle. This was 
       corrected.
    d) The following was detected on an alpha machine, but may be seen
       on other platforms (NEXT with absoft and  HP did not
       see it); "particle code=0 is invalid".  A potential cause 
       (may be dependent on the compiler) was eliminated.
        This bug was introduced in a previous release.
  2) Related to the DEC alpha (compatible) with Digital unix users.
       The Lund code Fritiof produces an invalid particle
       code, though  very rare. The cause was not resolved.
       Since the events  without such a strange code seem to
       quite heathy, the present system issues a warning message
       (on error out) and neglects such an event and continues the job.
       If you want not to show the message, see cosmos/ZstrangeCode.h.

uv4.60
Release  '98/02/26
Bug fix. In Tracking/cxyz2prim.f, 
       subroutine cxyz2primD(a, b)
       gave a wrong answer when 'a' and 'b' are the same variable.
       This was corrected. This gave a wrong direction cosine if
       ObsPlane=2.

       Some bug correction of Lorentz boost for special conditions.
 
       Probably due to this, DEC alpha machine become to be able 
       use the Lund code  without problems. (i.e., Elund*=500 is ok).
       
       Now, the random number seed and event number are written automatically
       to SeedFile if it is not ' ' even when Job!='skelton'.
      (In the case of Job = 'flesh', it is read).
       
       ObsPlane = -1 or -2 is supported.  Everything is the same as
       ObsPlane = 1 or 2, respectively except that the coordinate 
       system of particles given to UserHook is the Exyz.
     
       XaxisFromSouth is added to the 2nd group of the input parameters.
       This is to specify the angle between the horizontal detector 
       X-axis and the south (deg). (+ is counter clockwise, i.e,  90.0 is
       east).   If its absolute value is > 360.0,  it is computed so that
       the magnetic east becomes the detector x-axis direction.

uv4.51
Release  '97/12/03
Bug fix.  In primary energy sampling, if the all of the following
          condition is met,
    1) energy is not in GeV
    2) mass is not negligible
    3) energy is by kinetic energy or momentum (optionaly in  /n)
  Then sampled energy was not correct or sampling failed.
  The bug was in cconv_prim_e of csampPrimary.f
  
  Change: In Zmaxdef.h,   max num.  of sites and AS sites is made to be
    20.

uv4.50
Release  '97/11/27
Bug correction.  The treatment of  the Lorentz boost  was
    not appropriate due to the change of the coordinate system
    from the main frame version. This was most strongly demonstrated
    in mu/e-neutrino ratio because the z-axis of the Lorentz boost is
    that of the muon direction. The ratio was too big in all the unix
    versions.
    The effect seems to be also seen in the spread of high energy particles
    (say, gamma family), and in their bit smaller energies.  Accordingly, A.S
    size has been underestimated by 10~15 %. 
*** Gamma/Electron primary showers are free from this bug.
*** Also if only the Lund code is used for hadronic interactions,
*** the bug effect will be seen in the mu/e-neutrino ratio.

Bug correction. (no effect on the result).  The subcode for the gamma ray
    should be different  whether it suffers from cascade or not.
    This was not realized so far, but is implemented in this version.
   (subcode = kcasg, kdirectg)
Bug correction.  One dimensional mode calculation was totally not
    usable in the recent versions (>=uv4.0).  This was corrected.
   OneDim =0:  three dimensional.
           1:  One dimensional without table use for length<->gramage
           2:  One dimensional with table use for primary cos < 0.5.
           3:  One dimensional with table use for any angle.

Improvement:
   In the primary table, you can specify a minimum energy which  is 
 higher than the one given in table columns. This will enable the
 use to use the same table with different minimum energy without
 changing the table content.

   Some users prefer to use larger arrays than the system defaults.
 (say, for larger number of observation sites). For such purpose,
 cosmos/Zmaxdef.h may be used.
     
Bug correction.  Tracking/Atmosphere/cthick2len.f had a line
containing "maxkg2=1000".  This was too large if the particle angle is
large and resulted in an occasional incredibly long computation time.
If we put the value 100, everything seems to go well.
However, I put a more sophisticated modification.

 The explicit Moliere scattering formula is added for 
multiple scattering(see Note below). Before this version, a sophisticated
Gaussian approximation has been used in which the gradual
change of air density and constant dE/dx were taken into account.
The Gaussian approximation is very good for e-m cascade and the result
shows no difference from the Moliere method; this is due to the
fact that distant particles are mainly composed of low energy
particles suffered from scattering angle in the Gaussian part,
but not of those suffered from large angle scattering.

  One may, however, think that muons might be affected 
by large angle scattering since they don't suffer from cascade process.
For muons in the atmosphere, however, the large angle effect is 
expected to be masked due to the magnetic deflection and 
moreover transverse momentum at particle production.

 In fact, as shown in the following table I, the effect for
proton primary showers are not well seen in spite of the fact 
that the clear effect is obvious for virtual single muon incident case. 
(Table II).
 Although the previous treatment is good enough we introduced a parameter
"Moliere" in this version as follows.

 Moliere =0:  Old scattering formula is used. No change from 
	       the  older versions.
 |Moliere| =1:  Moliere scattering formula is employed only for 
               non-electrons. If this 1, for the
               angular-lateral correlation, we use the correlation
               function obtained by the Gaussian approximation.
               If it is -1, we neglect the lateral deflection.
 |Moliere|= 2: The same as above applies to all charge particles.

*** Note *** 
 Many of you might think that Moliere's theory is almighty (or best)
for multiple scattering. But things are not so simple in
Monte Carlo's which must see angles as well as positions.

 There is a certain correlation between scattering 
angle and lateral spread.  With the Gaussian approximation, the
lateral spread <r'> = a'*t/2, where t is the distance travelled,
a' the scattered angle.  For a given sampled a', the Gaussian 
approximation gives us an explicit correlated function for r'.
This correlation is important to get a correct lateral spread.
However, it is not possible to obtain a correlated distribution
in the Moliere theory. We follow the Gaussian prescription
after obtaining a scattering angle by Moliere's theory if 
Moliere > 0.  I am not sure whether this prescription is very
good or not. (At least for e-m cascade, the results are the
same as the Gaussian case).


uv4.12
Release  '97/06/21
Since the source file in the web site was short in the total
file size (due to ftp problem?), the complete one is 
sent again.  To do so, I changed the logic employed in
uv4.11 a bit.  In version 4.11, I used
  leng = leng * 1.005
This worked fine at least for 1000 showers.  When I made
  leng = leng * 1.0005
I met failure after some shower generation.  In this, version
I put absolute value shift to the leng, i.e.,
  leng = leng + |0.01/dircos.r(3)|
This means the crossing point is made to be 1 cm apart from
the real observation level. 


uv4.11
Release  '97/06/17
Bug correction for infinite loop.
In  cifXObsSites.f,  at line 175,  there is a line

 leng= (ObsSites(loc).zpl - ...

one more line should be added after this to make sure that
the particle crosses the plane.

 leng = leng * 1.005



uv4.10
Release  '97/06/14
Bug correction and improvement:

1) If "generate" included 'as' and a high energy electron  goes
upward,  A.S generation routine encountered an error in
clenbetween2h and stopped (That is,  the generation of A.S by up going 
particles was not possible).  This bug was corrected.

2) Also there was a problem in individual particle
observation  when a particle goes backward.  This was
corrected so that up going particles can be observed.

3) If ObsPlane is 1 (horizontal) and a particle crosses an observation
plane at very far distant place from the core,  the trace information
z-coordinate value (expressed in air thickness) was not correct.
This bug was also corrected. (This is due to the Earth curvature).

4)If an incident particle had negative zenith cos angle, 
   it was regarded that the particle was injected at the
   "conjugate point" of the earth with the positive cos angle.
  (This is for neutrino observation when a primary comes from
   below the horizon).
   If the negative zenith angle is taken always like this, we
   cannot simulate the case where an incident particle really
   goes upward direction (to the outer atmosphere; this may happen 
   if an up going  neutrino makes an interaction near the
   surface of the earth and produced particles emerge from
   the surface).   In this version, we interpret the
   negative zenith angle (given by coszenith) as that of an up going particle
   if HeightOfInj is lower than the deepest observation level.
   In this case, you must give BorderHeightH explicitly.

Release	 '97/05/17
1) A new user interface routine, chookHybAS, is added to manage hybrid
  air shower generation.  It is called when a component shower from an
  electron is added so that the user can make some additional
  computation for such a component air shower.  The routine is
  primarily intended to be used for generation of air fluorescence light.
  The file chookHybAS.f is in UserHook. Every one must include it by putting
  #include "chookHybAS.f"  in one's hook routine to avoid unresolved
  external reference.
2) For air fluorescence light, new routines are added to be able to
   get the temperature of the atmosphere, and effective <dE/dx>.
   The interface is:
     real*8 cvh2temp(vh, tk)
     call cavedEdx(eno, age, dedx)	
   where vh: vertical height, tk: temperature in Kelvin,  eno: Ne
   age: age of the shower, dedx: effective  <dE/dx>.
   tk and dedx are output and others are input.

The assumed usage for air fluorescence light generation is one of the
following two:
1) manage fluorescence light generation business for each component
   shower.  The user may enrich chookHybAS.f  for this end.  
2) manage fluorescence light generation at the end of each shower generation.
  That is, the user may manage it in chookEnEvnet.  
   

uv4.01
Release  '97/02/12

1) A new treatment is introduced to have a faster execution of one
   dimensional calculation at large angles (cos(zenith) < 0.5).
   Although it uses tables and interpolation, accuracy is high.
2) For Cerenkov light calculation, the user can give Trace > 160,
   in which case the user can manage the charged particle track
   information in the user hook. This means, the user can convert
   the track  information into Cerenkov light in his/her desired
   form on fly. This is to save large disk volume which might be
   needed if the user writes the track information directly.
   For this end, template routines, chookCerenS, chookCeren
   and chookCerenE, are supplied in the ctemplCeren.f file in
   UserHook. The user may copy these into chookCeren.f and
   fill the content. (See ctemplCeren.f).  The track info
   coordinate is the same as Trace-100 --> Trace.
3) DestEventNo is now an integer array of dimension 2. 
   The first one is the number of events to be generated
   ultimately, and the second one the number to be generated 
   in the current run.  If it is not given, DestEventNo(2) is 
   the same as DestEventNo(1).  If you give some value smaller
   than DestEventNo(1), the current run will stop when Cosmos
   generated such a number of events in the run.  The user may
   give 'Cont =t' in the  parameter file and continue the 
   next run to generate another DestEventNo(2).

   For first run:   cosmos < param     
   Then, change "Cont = t" in param.
   For 2nd run, 2rd run,  cosmos < param.

4) Bug correction, at very high energies, the eta meson may not decay,
  and may collide with an air nucleus. The leading particle treatment
  was missing for eta and this was corrected (in cfclp of cs2lp.f)
  so that the program  execution dose not stop. 
  	
uv4.00
Release '96.11/04

Bug corrections:
First of all,  who is safe ?

1) If you are using gamma/electron primary. (Provided that
   you are not dealing with muons coming from photo-production
   of hadrons). 
2) If you are not using uv3.00 to 3.50, not using Absoft Fortran
   and primary enegy is < ~10 TeV. (There is known bugs in versions
   before uv2.203, so you must bypass such bugs in this case).
3) Relatively safe:  If your condition violates 2) above, but if you 
   are doing simulations at high energies and not dealing with muons in A.S.
   Effect will be small. There might be some over production of 
   gamma/electrons.

----------bug details.

1)  Version uv2.203 to 3.50 have a bug in a nuclear interaction routine,
    nucrin, which is used for hadoron nucleus collisions  below 5 GeV.
   (No particle is produced). This is due to a mistake introduced when
    I changed all external names in old Lund-related codes so that
   they might not collide with those in the new Lund code.  
    Some external names had not been detected for change.

2) In the adhoc phenomcnological model, pion interaction has a bug.
   Due to a mistake when the code for the main frame was rewritten for  
   unix, the leading pion after a collision all changed into pi zero.
   This has a big effect on the low energy muons in  air showers.  The
   effect is as large as factor 1.6. (For 100 TeV protons; if one doesn't
   use Absoft fortran which employs the adhoc even below 500 GeV. 
   The Abosft fortran users would have a correction factor as large as
   2. There  will be some over production of gamma rays.  

3)  Successive interaction probability in a nucleus is revised and it is found
   that the  probability of larger number of successive interactions is 
   bigger than  than older version.  The multiplicity increase as compared
   with the older  versions is rather tremendous.  However, the effect is 
   only in the  muon numbers in the air shower and estimated to be order
   of 15 % at 100 TeV region. But the effect will be much large at higher
   energy.  Since the treatment is based on a geometrical picture, I am
   not completely confident with this new version. The user can choose
   the old version or this new version by giving SucInt = 0 or 1,
   respectively.   The default value is 1.

4) One can specify the azimuthal angle range for isotropic zenith angle
   input.  The new parameter is Azimuth. For example, Azimuth=(0d0,35.d0),
   will limit the azimuthal angle range between 0 to 35 degrees. The 
   angle is measured in the (lowest level)  detector system of which
   x-coordinate  is directed to the magnetic east and the y to 
   magnetic north.


uv3.50
Release '96.10/01

 1) Bug correction: Infinite loop sometimes occurred with small KEminObs
    (say, KEminObs=0.5)  has been corrected. 
    The problem with small KEminObs has been treated very carefully, but
    there still existed a bug. For example, even when an anti proton energy
    becomes  smaller than KEminObs, we cannot discard that anti-proton if
    KEminObs is small, because, anti-proton annihilation may generate
    particles with kinetic energy > KEminObs.  This fact brings some
    difficulty in particle following;  Some worst case may be stated that
    anti-proton stops in "vacuum" so that it cannot move nor annihilate.
    Similar problems occurred for particles that can decay.  These
    bugs are eliminated in this version.
      Floating exception bugs:  There found two of such; one in ckaonDecay.f
    and the other in aadn.f. There are both sqrt(-eps) problem, where eps is
    ~10^-6.

 2) A class of calculations such as muon observation with hybrid air shower
    size is assured to be run fast, if one dose not need to
    include small number of muons coming from photo-hadron production.
    In this case,  one need not follow e-m cascading to a low energy.
    The codes so far released should have been constructed to be able to do
    such jobs, but I am not sure it was really supported correctly,  
    because some user reported he needed  30 min. for making one
    event with KEminObs = 1.0 for a proton primary of 100 TeV. 
    The event could be generated in 10 seconds or so with Pentium
    100 MHz machine. The present version is confirmed that such a 
    function really works.  Also I confirmed applicability of
    'skeleton/flesh-out' method. 
 3) Some inconvenience for simulating very high energy showers (gamma with E
    > 10^19 eV) have been eliminated. (Say, overflow due to multiple scattering
    at very high altitude such as 1000 km where there is no air
    and the scattering can be neglected).  The default parameter values
    for the LPM and magnetic effects was adequately fixed.

 4) Eta-meson production is explicitly taken into account from this version.
    Etas are neglected at low energies because it is almost equivalent to
    pi0's.  (We explicitly  introduce eta if the number of pi0 exceeds 10).
    However, the role of eta is at E > 10^19 eV where pi0 becomes
    unable  to decay and only eta's can be a source of high energy gammas
    for which the LPM effect may works. Its finite life time is also taken
    into account because it will become important for proton primary of
    ~ 10^22 eV.  There is a parameter, Eta2Pi0,  which is the ratio: eta/pi0.
    The default value is 0.2
   
uv3.10
Release '96.09/18
 1) The second  random number generator which is used only in flesh-out
    time is found to generate exact 0; this is not desirable and corrected.

 2) The skeleton/flesh-out logic was changed to be much simpler one, 
    although  the  usage is unchanged except for the following case.
    There was one bug in skeleton/flesh-out method when the user add
    deeper observation level(s) at flesh-out time;
    fortunately this function has not been used any body yet.

    To correct the bug, the following change has been introduced.
    If the user wants to add deeper observation level(s) at flesh-out time,
    he/she must give the entire observation depths (let the number of depths 
    be N) at the  skeleton making  time. To be able to terminate the
    particle following  at some depth which is not the deepest one,
    the user may specify the depth by the 'EndLevel' parameter (<N;
    2nd parameter) at the skeleton-making time. This number must 
    be changed to a larger one at flesh-out time.

 3) Easier parameter setting is possible for
    the hybrid AS simulation at very high energies
    where we must take care of LPM and magnetic effects (This is owing
    to the simplification of the skeleton/flesh-out logic).
    Also  less  time is needed to get reliable results.

    The meaning of RatioToE0 has been changed:
    The parameter, RatioToE0  (default value is 10^-5), is used to
    compute the minimum energy of (hadronic) particles to be  followed
    as minimum=(E0/nucleon)*RatioToE0.  At very high energies, 10^-5
    may not be small enough; ~10 percent smaller AS size may be obtained.
    However, you must know decreasing this by one order results in 
    ~5 time longer execution time.  In normal applications, WaitRatio
    may be 1.0 for non-e/g primary, and 0.01 for e/g primary.  However, 
    it must  be as small as (E0/nucleon)*WaitRatio = 2x10^16 ~ 10^17 eV
    to take into account the LPM and magnetic effect properly.
    For 10^21 eV primaries,   WaitRatio of 2x 10^-5 ~ 10^-4 is needed.
5)  Probably you noticed the following bug; the standard chook program
    out put the parameters and some others on stderr. However, some of 
    them appeared on stdout and this cannot be ceased until you
    comment out the corresponding subroutine call.  This was corrected
    so that you can redirect standard output to a disk file without 
    contamination. (Note: Absoft Fortran produces 1 line out put
    on stdout when it read namelist data.  This cannot be avoided,
    so the standard output always  involves contamination)
------------------------------------------    
uv3.02
Release '96.09/14
 There is another problem for DEC compiler.  Manager/cmanager.f has
lines:
      external ludata
      external luedat
      external luhdat
We have to append C (capital C) to each of the three lines;
      external ludataC
      external luedatC
      external luhdatC



uv3.01
Releas '96.09/14

 Since DEC Fortran cannot properly treat statement like
  sing(1., x)  
  cmplx(1., y)
where x and y are double precision real variables, corrections
are made in Import/NewFritiof/pythia.f and jetset.f

uv3.00
Release '96/09/13

I)   A new Lund Monte Carlo program, Fritiof (V.7.02), was implemented for 
     the hadronic interaction model. This one has been supposed (by me) to
     be applicable upto the SSC energies. (But there are problems and I am 
     skeptical about its applicability to cosmic ray  physics. See
     details later).

II)  Accurate formulas including quantum effect were implemented for the
     magnetic bremsstrahlung and pair creation (The previous version had
     almost correct ones, but there was one problem in tracking particles
     when the magnetic effects are important).  

III) The default interaction model for NEXT (Absoft Fortran) is changed to
     IntModel='int1' instead of 'int2'. It has been found by some users 
     that the Gheisha code (which has been the default for NEXT) gives too 
     wide lateral distributions for muons  and electrons as compared to the
     Lund/ad hoc model which give consistent results with the experimental 
     data.  Gheisha is now put to a non-default code.

IV)  The program was modified so that the user may get the nuclear interaction
     height of a given observed particle.

V)   There are two changes in the ad hoc model tuning.
     One is the transverse momentum at very high energies (> 10^16 eV).  The 
     (hopefully) correct high Pt tail can be reproduced in this version 
     (older versions have smaller probability of producing high Pt), 
     although its effect is expected to be very small in the observation.

     The other one is related to the multiplicity .  This version has 
     SMALLER multiplicity (by about 10 %) than the older ones at > 10^14 eV, 
     in spite of the fact that many cosmic ray people tend to like a higher 
     multiplicity models. Why the change ? See later.
     
     Effect: May be seen only in muon numbers with low energy threshold;
     I expect a few percent reduction.  Air shower size will not be 
     affected.
VI)  Spell check has been done for Doc/ParamUsage* which are generated from
     some #include files. Since many #include files have been touched,
     'make' will recompile many files. 


-----------------------
Details:
I)
The new Lund Fritiof consists of:
Fritiof      (managing interactions)
Jetset       (for fragmentation)
Pythia       (for hard scattering)
Ariadone     (for gluon radiation)

The model is said to be applicable at  E(lab)> ~100 GeV. (At least root
 s > 10 GeV).
Accordingly, new parameters, Elund2, Elund3, LundPara were introduced.
The new Lund codes are employed if the particle energy, E,  is 
 Elund2 < E < Elund3.
In this case, Elund2 must be > ~ 100 GeV.  

The energy scale and code to be used are;
--------- 5 GeV---------Elund--------Elund2------------Elund3---------------
Nucrin/Hadrin     Old Lund     adhoc          new Lund         adhoc  (int1)
        Gheisha                adhoc          new Lund         adhoc  (int2)

However, the user can adjust Elund/Elund2/Elund3 so that, for example,
one can use only the adhoc model at E> 5 GeV. 
The typical setting will be:
1)  Elund=Elund2=Elund3=500 (default). Effect: the same as the older version.
2)  Elund=Elund2=Elund3=4.99 (default for  Absoft compilers).   Effect:
    only adhoc model is used at E> 5 GeV.
3)  Elund=500, Elund2=500, Elund3=1.e30. Effect:
    At 5 < E <500 GeV, old Lund is used.
    At E> 500 GeV,     new Lund is used.
Caution:
 Although the new Lund codes may be good for hard processes,
 its use for cosmic ray is very much questionable.

Some characteristic features of the new Lund code relevant to cosmic 
ray physics are:

1) The x-distribution of pions and kaons in the fragmentation region 
   almost completely scales. This is different from the adhoc model where
   we see some weak scale breaking in the fragmentation region.
2) On the contrary, the x distribution of nucleons in pp collisions dose
   not scale.  Especially, the diffraction peak disappears
   and the leading particle becomes less and less prominent at higher 
   energies.  This would be inconsistent with the tipple Regge theory.
   (See fig. in the Web site).
3) The average multiplicity (as a function of energy for pp collisions) is
   smaller than the adhoc model, if we use Fritiof hard process (see below).
   (at > 10^15eV).  However, at SPS energies the Lund gives a little too
   high multiplicity than the adhoc and UA5 data.
   If we use Pythia hard process (see also below). the multiplicity is
   increased and in some case exceeds the adhoc model.
  
     For p-air collisions, the Lund code gives higher effect than the
   adhoc model.
4) The new Lund codes cannot reproduce UA5 results (pseudo rapidity data).
   The difference from the  experimental data seems too large to be
   attributed to some experimental biases.  (See Web fig).
5) The x-distribution of nucleons in pp collisions differs from that of
   old Lund even at few hundred GeV, and seems contradicting to
   experimental data  (see Web fig).

New Lund code has some tuning parameters. Typical ones are:
  a) use Pythia for multiple hard scattering process or use Friitof's
     simplified method.
  b) OPAL or DELPHI parameterization for some hard process.

Other problems:
  As mentioned in 3) above, depending on whether we use 
Pythia hard process(Fritiof parameter, kfr(7)=2) or Fritiof hard
process( kfr(7)=1), the average multiplicity  changes considerably;

            ---Table---(See also Web fig) 
 The total multiplicity for pp collisions (upper)
 and p-Nitrogen (lower). (excluding the elastic events)
Errors in the table values are expected to be order of few percents.
(Typically 2000 events are generated, the standard deviation is order of
the average value (bit smaller), so you can estimate the errors. Only 1000
events were generated in some high energy cases) 
                          pp
---------------------------------------------------------------
E0                10^12  10^14  10^15  10^16  10^18   10^20  10^21 eV
---------------------------------------------------------------
adhoc before v3     19.1    48   69.2  100     207      390    558  
     charged        11.7         40.7          117             308

        v3          18.2    43.6 63.1   91.1   181      369    489  
     charged        11.4         37.2          103             268       
 


Lund    kfr(7)=1    19.1         62.5          151             313  
  // charged        11.1         37.4           90             186

Lund    kfr(7)=2                 75.4          201
                                 44.9          120

Lund    kfr(7)=1    19.3    45   67.5   85     153      248    336  p-d
Lund    kfr(7)=2    20      53          99     199      381         p-d

                        p-Nitrogen
---------------------------------------------------------------
adhoc  bef.v3       27	    70   112  160      336             892   p-Nitrogen

  v3.0 SucPw=1.5    25.3         104           312             869   //
  charged           15.3          61           177             477  

  //   SucPw=0.5                 108                                 //

Lund    kfr(7)=1    28.6         118           313             697  p-Nitrogen
                    17.1         70.4          186             413
 	                                                     (681 events)

Lund    kfr(7)=2    30.0
		    18.0
-----------------------------------------------------------

                   comparison with the  ua5 data

roots (GeV)      53         200         546        900

ua5 data        
    charged     11.7        19.5        27.5       32~33

adhoc v3.0      19.9        33.5        47.2       55.3
	        12.3        20.2        28.1       32.7

Lund  kfr(7)=1  20.6        35.0        47.4       56.1     
                12.5        21.0        28.5       33.7  

Lund  kfr(7)=2  22.2        43.3        56.7       65.6      
                13.5        26.0        34.0       39.4
 
------------------------------------------------------------------
at 10^15 eV
               Lund                             Adhoc  
         pC       pN         pO              pC        pN        pO 
       114        118        114            104        104       110    
        67	  70.4       68              61.2       61       64.7  


 
When we look into the multiplicity distribution of the Lund result with
 kfr7)=2, the shape is roughly as follows and it indicates  kfr(7)=2  has 
a problem.  (See also Web fig). I wrote a letter to the auther of Fritiof
about this but no respose yet.

|    +
|   + +      rough sketch of multiplicity
|     +     distribution at 10^20 eV with kfr(7)=2
|   + +           +
|  +   +        +    +
|  +    +     +       + +
| +      +   +            +   +
|---------|----------------|----->
0        500              2000   # of total particles


The  kfr(7)=1 case gives smaller average transverse momentum (13% smaller
than the case of kfr(7)=2 at 10^18 eV).  The OPAL and DELPHI groups
parameterizations for some hard process are giving  some difference 
at very high energies:  DELPHI parameterization gives little bit 
larger transverse momentum (but may be negligible).

 The valley seen in the figure of multiplicity distribution with kfr(7)=2 is 
somewhat smeared out in p-air collisions.
  One more problem in the New Lund code is that it cannot treat
kaon collisions properly, since Pythia cannot accept it. Therefore, the 
code regards all sort of kaons as a negative pion. This will not be
harmful in may respect except for high energy muon observation. If
one is interested in high energy muons, such a treatment may have a big
effect, since the leading kaon  (which has still large energy) after 
collision has larger probability of decay than leading pion.

----------- change from original Lund code ----------
   To be able to use the New Lund code at very high energies, I made 
all real variable to be double precision and expanded some array size.
However, the array size is still not enough for 0.3 % of events at 10^21
eV p-O collisions.  The external names in old Lund code have been changed
so that they don't collide with the ones in New Lund code. (Actually, 
this had been done in the previous version already--> not true).
I confirmed that the strange results  are not due to this change; at
lower energies where the original code can work, we already see similar
phenomena and they coincide with  results by the changed  code.

  The random number generator is changed to the Cosmos supplied one
so that skelton/fleshout method is applicable.
-----------------------------------------------

************ Tentative conclusions about new Lund code ***********

You may use it as one class of models in which

1) secondary particle x-distribution completely scales,
2) leading particle becomes less and less at higher energies
   (increasing inelasticity with energy). No diffraction peak
   at high energies
3) inconsistent with UA5 data

and see what is the effect on observations.
	
To be able to choose the parametarization or modeling, LundPara
is introduced; it is a dimension 10 integer array and currently 1~5 are
used.
LundPara(1) (Default = 1); value for kfr(7)
        (2) (Default = 1); OPAL(=1) or DELPHI(=2)
        (3) (Default = 0); to suppress  some message from Fritiof(=0)
                           or positive value for message. It is put stderr.
        (4) (Default = 0): to suppress some message from pythia (=0)
                           or positive value for message. It is put stderr.
        (5) (Default = 1); When New Lund is used, kaon collision is treated
                           by the adhoc model (=1) or regarded as a negative
                           pion (!=0) in New Lund.




IV)
  Since one user wanted to know the production height of an observed
particle, the Cosmos code was modified a little bit. (This feature was
supported in the main frame version). 
  One may wonder how one should define the production height of a given
particle.  Take an electron, should we define it as the point where a
gamma ray made pair creation (then, if there is a lot of cascade, 
which pair creation?), or pi-0 decay point, or nuclear collision point ?
  The resolution here is to take the nearest hadronic collision point where
the parent of a given particle is produced.  To be able to get such info,
we have to increase the track attribute; if 'aTrack' is a
 record /track/ aTrack,
then
 aTrack.colheight
is to keep such height in m from the sea level. 
(colheight is the vertical height).  One may subtract the  height of
an observation site from this value to get the production height.
If a primary is a non-hadronic particle, or a hadronic primary dose
not interact and reach an observation level,  colheight becomes very large
value(> 10^37), and if you convert it single precision, you may get
 +INF (I am afraid you may get error in some system)
  Since there is changes in the program,  skeleton data created by the older
versins  is not usable for fleshing-out in this version.


V)
    I found one mistake in the previous tuning in the phenomenological 
    ad hoc model. It intruded when I rewote the main frame version 
    for the unix version. At that time, I retuned the code using UA5 data.
    When I should have used UA5 inelastic data, I used UA5 non-single 
    diffractive data by mistake.  This resulted in higher multiplicity 
    and stronger energy dependence of the average multiplicity increase
    than the present correct tuning. 
    You will see a figure in the Web site that shows very good fit to
    UA5 inelastic (minimum bias) data by the present version.
    The tuning is very sensitive to the multiplicity and its energy
    dependence. The absolute value of the (charged particle) multiplicity
    must be tuned within ~0.5 particles and the power of the  energy 
    dependence is within ~0.003.  However, nobody knows that the
    extrapolation of this to 10^21 eV is valid or not.


---------------------------
uv2.203
Release '96/02/26
   A bug correction. The number of particles observed at near sea level 
was too small; such particles were counted as being reached the
BorderHieghtL and not judged as crossing the observation plane.
This was corrected.  The effect was serious for muons at near
sea level.

uv2.202
Release '96/02/02
   In the previous version, I forgot to correct a mistake in
the charge assignment; in the photo-hadron production, 
positive charge excess occurred which must not exist with
the air target.

uv2.201
Release '96/02/02
  Bug correction for photo-production of hadrons.
  There is still one more fatal mistake in Particle/Event/GammaN/cgpHad.f.
  At around line 83.

        elseif(jtype .ge.  3 .or. jtype .eq. 4) then
c         now in cms. boot to lab

  should be read as

        elseif(jtype .eq.  3 .or. jtype .eq. 4) then
c         now in cms. boost to lab

       There was a misleading comment in chook.f, chookSample.f
   etc, about particle trace by the user option, like, if
    Trace > 60, chookTrace is called.
   This should be read as Trace > 100.
   In chook.f, one example of  using Trace > 100 is embedded;
   This example is to use standard output procedures for Trace
   but output only muons.


 

uv2.200
Release '96/01/24

  Bug correction for photo-production of hadrons.
  There is mistakes in particle number setting.
  4 body decay( gx --> x + 3pi, x= p/n ) sometimes fails after 20 trials
  due to wight problem (few %). However, failed events have statistically
  no special bias, they are now accepted, and program execution continues.
  

uv2.107
Release '96/01/01

Effect: For cosmos users, none.  This is to eliminate some name
      collisions with epics.  (Zdedx.h)


uv2.106
Release '95/12/27

  Effect: In the E> 10^15 eV region.  There may appear some
	difference if you investigate high energy muon bundle
	dicoherence curve etc.  In the older versions, the 
	occurrence of high 
	transverse momentum was somewhat underestimated.
  All figures in the Web site were created by using this version.

uv2.105
Release '95/12/20

  Effect:
  1)  Hadron primaries (p, Alpha, ...Fe;  E/A > 500 GeV).
    As to the heavy particle interactions, there was a typo which 
    invaded into the code after program check!
    The effect is in the number of successive interactions of
    a leading hadron  and the inelasticity of successive interactions
    inside an air nucleus.
       This effect, however, was compensated at very high energies due to
    other inconsistency of the sampling method of interacting nucleon
    numbers :-).  These were modified in this version.  Also the energy
    dependence of heavy interaction cross-section is introduced (See below).

    There is some theoretical uncertainty in how to count the number of
    interacting nucleons in heavy nucleus interactions. (I think).  The
    resolution is to make a new parameter 'HowIntNuc':
    HowIntNuc = 1 (default) will give larger number of interacting  nucleons
    than HowIntNuc=0.
	
  2) Air showers generated by the hybrid method was wrong for
     zenith angles > 60 degrees. It is obvious when you look
     at the result. So I believe no body has tried it yet. This
     was already reported soon after the release of uv2.000. Also
     the cause of an arithmetic error which takes place on some machines
     was eliminated. This is also the one reported at the same time.
  
  3) Some corrections for DECALPHA compilers.  (common data alignment,
     save statement for record)

  4) The adhoc model of nuclear interactions is modified so that the
     x-distributions of pions and kaons etc are little bit softer
     than the older versions.  This effect is expected very small.
     Although the adhoc model has been used at > 500 GeV, the new
     version can be used down to 5 GeV or so. (See fig. on Web)
	

 New features.
  1)  DECALPHA with a new environment (Digital Unix) is supported.
    The DECALPHA users  may copy site.configDECALPHA2 to site.config.  
    Both the native "make" and "GNU make" should work.
    If new site.config  fails, try, site.condfigDEDALPHA as previously. 
  2)  SGI has been verified to work (from Dr. Dai, Utha). 
     site.configSGI is ready for use.
     To be able to use SGI, you have to copy cmain.f in Manager directory 
     to the UserHook directory and explicitly use it at the compilation 
     time. Equivalently you may add a line #include "Zcmain.h"
     at the top of your user hook routine.
  3) The Gheisah code for hadronic interactions is available for use.
     Gheisha is a code for hadronic interactions in GEANT. To use it
     instead of the  Lund/Fritiof/Nucrin/Hadrin set, give IntModel="inte2".

     *********************************************************************
     In particular, Absoft compiler users should use this parameter value.
     or make Elund=4.99 with IntModel='int1'. In the latter case, the adhoc
     nuclear interaction model is used at E > Elund;  at  E< Elund, Nucrin/
     Hadrin are used.
     *********************************************************************

     If IntModel='int2', Gheisha will be used when a hadron energy becomes
      < Elund,  of which default is 500 GeV. Above this energy, the adhoc 
     model is used as in the case of 'int1'.  Some comparison data among
     Gheisha, Lund/Fritiof and adhoc model is available  on the Web site. 
       As you see in a figure there, Gheisha behaves rather awkwardly at
     500 GeV. I don't think it's good to put Elund > 500 GeV for Gheisha, 
     too.  Also Gheisha seems to give some strange results for nucleus 
     target as  you see in Figs in the Web site (I hope this is not due
     to my mistake). The effect may not be seen in the Cosmos results.

     Some detailed notes:  Gheisha 
     produces alpha, triton and deuteron from the break up of a target
     nucleus, while Nucrin treats the evaporation  process as 
     energy loss.  Alpha, triton and deuteron can be an input to Gheisha;
     however, if you have a chance to use Gheisha code yourself, you 
     should not try to input  such a particle at high energies to Gheisha,
     because they never break up in Gheisha.   (Cosmos
     does not input heavy particles directly to Gheisha/Lund.)

     . Gheisha gives systematically smaller multiplicity than Lund
     . Gheisha gives less significant quasi-elastic peak of the leading
       particle than Lund.  ( Gheisha includes elastic scattering
       separately).  
     . Gheisha seems to break  the energy conservation by about 10 % in
       the worst case. (see fig. for 10 GeV)
     . In Gheisah code, there is a switch for using Nucrin/Hadrin code at
       energy < 5 GeV.  This is set to be off in default.  Since the codes
       for Nucrin/Hadrin are the same as in the existing Cosmos codes,
       those in Gheisha are hidden for the compilation, otherwise the
       external name collision occurs.  Although the names are the same,
       some subroutines have the different number of arguments and/or
       different internal code, the user should never make the switch for
       Nucrin on in Gheisha code.  (Therefor, there is no parameter for
       that in Cosmos).
     . Gheisha seems to behave awkwardly at 500 GeV and for nucleus targets.

  4) Air shower generation by heavy primaries such as Fe at 10**18 eV takes
     very long time(~4 hours/shower on HP735),  even if we use the
     hybrid method.  
     To save this, a new feature is introduced.  The idea is to replace
     an interacted nucleons by a precomputed air showers generated by 
     a nucleon.  You may use chookASbyH.f  and chookASbyH2.f in UserHook.
     I didn't encapsulated the necessary procedures inside the Cosmos library,
     so you need some programming in chookASbyH2.f.  
     This is to keep flexibility for handling air shower generation 
     in future; we need to include muon  generation, their lateral
     distribution etc.  After every details are fixed, I would encapsulate
     the procedures.  To enable the feature, put Generate ='qas', 
     instead of 'as'. For  further details, see chookASbyH.f.

  5) The interaction cross-section of heavy primaries has been kept constant
     in the older versions, since it is weakly energy dependent even if the
     proton interaction cross-section increases as energy goes higher. In 
     this version, I included their energy dependence at high energies
     (E/A > 500 GeV).  I found a good formula for this; when the
     pp cross-section goes as E**d (which is a good approximation at
     E> 1000 GeV), AB interaction cross-sections goes  like E**d' with
      
        d' =   2.5d/(p + q + pq/2)

     where p= A**(1/3) and q = B**(1/3) (A and B are the mass number of
     projectile and target nucleus). The cross-sections thus obtained
     are compared with  Engel, Gaisser et al's calculations
     (PRD vol.46, (1992)5013 on the Web site.
  6) In the adhoc model, the inelasticity of a leading particle at
     the 2nd, 3rd,.. collisions inside a nucleus should be more
     elastic than normal ones; the x distribution is expressed
     simply as  x**SucPw dx.  SucPw is known to be good within 1. to
     3. The default is 1.5. The user can adjust this value in the 2nd
     namelist parameter.
  7) The total particle multiplicity in the adhoc model is expressed by 
     7.2 roots**0.254 - 7 
     according to UA5 parameterization.  Another choice is possible by
     giving MulLow = 1 for which we use QCD jet prediction at high
     energies ( roots > 1000 GeV );
     0.6135exp(sqrt(23/18* 2log(roots/0.3))).
     The default value of MulLow is 0.  This latter formula is adjusted
     to coincide with the first formula at roots = 1000 GeV.
 

uv2.000
Release 19, Sep.1995
A lot of things.
!!!!!  Things not listed in the release time
      The size of the particle array to store produced particles
      at an interaction is enlarged to 4500. This will be enough
      to contain particles at 10^21 eV proton interaction which
      produces about 900 particles on the average.  10^22 eV may
      be also acceptable.
      The size of the stack to store particles for tracking is
      enlarged to 15000.  This will also enough for 10^22 eV.

      The output format of trace data (not of Cerenkov) is 
      changed so that the size of the data becomes small
      (as small as half, probably).  If the old systematic format
      is better, it can be done by changing the one variable
      in the trace routine. (but not by input parameter).

**********
Magnetic bremsstrahlung and pair creation have been introduced at 
high energies.

For gamma primaries, they are significantly effective above 5 x 10^19 eV.
The m.f.p of M.B is about 5 km at 10^17 eV, and becomes gradually 
longer (due to less deflection). However, the emitted photon energy
becomes gradually higher and hence it becomes catastrophic.  The total
energy loss at 5 x 10^19 eV is about 10 % for single emission.
The m.f.p of M.P  is 6 km at 5x10^19 eV and becomes 400 m at 10^20 eV.
At 3x10^20 eV it is as small as 20 m.
The following parameters are introduced in the second group.

MagBrem =0  Magnetic bremsstralhung is not considered.
            (see also UpsilonMin)
        =1  Total energy loss is considered.
        =2  Actual emission of gamma is considered.
            Default is 2.  If you simulate really high energy air showers
            with generate='as' and MagBrem !=0, you should set
	    WaitRatio ~ min(MagBremEmin/Primary Energy, 1)
MagBremEmin = 1.e9 (i.e. 10^18 eV.).  Above this energy, the effect is
              considered.

MagPair =0 Magnetic pair creation is not considered
        =1 Actual creation process is taken into account
           Default is 1
MagPairEmin = 3.e10 (i.e  3x10^19 eV.)  Above this energy, the M.P is 
             considered. 
UpsilonMin = 10^-3.  The M.B is actually considered only if the 
             upsilon=Ee/Me * Bsin/Bcrit > UpsilonMin.  Bsin is the effective
             magnetic field strength (i.e., abs(B x p/|p|))
       
          In the case of M.P, a similar parameter, xai, is used in the
          final decision and it must be > 0.2. For this there is no
          control parameter.

********
The Landau-Pomeranchuk effect has been included as described by  Migdals's
formulas.  The air density change has been adequately considered.
The relevant parameters are:

LpmEffect: (1st group).  T ==> effect is taken into account else no.
           The next two are in the  2nd group.
LpmBremEmin:  If the electron energy is > this && LmpEffect, the LPM effect is
        taken into account for bremsstrahlung.
LpmPairEmin:  If the photon energy is > this && Lpmeffect, the LPM effect is
        taken into account for pair creation.

********
Thin Sampling has been supported.  Although the parameters needed for this
existed from the first, real support in the unix version comes this time.
The relevant parameters are:

ThinSampling = F  Make this one .true. if you want thin sampling.
EthinRatio   = 3 x 10^-4. 
             If particle energy becomes < E0/nucleon * EthinRatio, 
	     thin sampling is actually attempted.
             A.S size calculation automatically takes the weight by
             the thin sampling.  If you look individual particles,
	     you have to account for the weight in aTrack.wgt.
  <<<<I don't recommend to use Thin Sampling because it leads to 
      very large fluctuations,  esp. in the 3 dimensional treatment >>>  
      Don't use with the skeleton/fleshing method.


********
The A.S lateral distribution by formula is  available for use.
At the end of an event simulation, in chookEnEvent,  you can call cqPtclDen
to get effective particle number (/m2) at a given core distance.
The present version should be taken as a tentative trial, though the
formula itself is reliable. Why ?  Ne or related observational quantities
are rather dependent on the detector structure and sometimes we have to
consider the cascading in the detectors.  The lateral distribution
supplied this time assumes some kind of detector structures.
 
During the computation of a shower, the air shower size is computed  for
a certain class of electrons and they are summed up to get final total size.
In the present version, lateral distributions for those ingredients are not
supplied.

********
The Air Shower generation has been made to be more systmatic.  The minimum 
energy the user can give is KEminObs which is for the observation of each
particle.  If AS observation is specified, Cosmos uses various minimum 
energy internally.  Roughly speaking, if only air shower generation is 
desired, hadrons are followed until they reach the energy, (irrespectively
of KEminObs, hence, you may give this a very large value if you don't
observe individual particles),

EminAS = E0/nucleon x RatioToE0.
 (note: for gamma, for instance, per nucleon energy is the primary energy)

Electrons and gamma rays are followed until they reach 1/30 of this energy.
(In the previous version, they are not followed to such a low energy).
Air Showers are generated by formula from each electrons.


Hence, at high energies, AS generation will have the following scheme.
     

                       EminAS              E0
        hadrons:       |--------------------|  
                              full M.C
                 EminAS/30
        gammas     |------------------------| 
                              full M.C

                                 WaitRaio*E0
        electrons  |***************|--------|   
                                     full M.C
                     Electrons falling in the * region will generate
                  A.S by formula and then discarded.

At moderate energies where the LPM, the Magnetic effects are negligible,
you may use WaitRatio = 1, for hadron primaries.

*********
Energy loss formula was updated so that dE/dx at Ekin < mass is correct.
This effect would be small but the user should see it.

*********
Infinite Loop at very low energies (Ee < 1 MeV) was corrected.
This happened in Molloer scattering.

*********
Backward going particles sometimes generated errors; this was corrected
so that we can trace a particle until the height of Earthradius x 10 
safely. 

To make sure that infinite cyclotron loop be sidestepped,

PathLimit

may be given.  Default is 20 x Earth_radius.  If a particle move more than
this length, it is judged as dead. Note, however, if you use the default
parameters setting, this value is not referenced actually; BackAngLimit
will prevent the particle going backward.

  We can use Cosmos to make geomagnetic cut off table.
To do so, new parameters have been introduced, (2nd group)

Reverse:   0(default) ==> normal simulation.
           1  ==> given incident particle is charge-conjugated and
                  made to go to a direction opposite to the given
                  direction. All interactions except for magnetic
                  deflection are neglected.
           2  ==> the same as 1 but energy gain (not loss) in 
                  air is considered. 
Note that to use Reverse !=0, the following point should be
considered.

HeightOfInj;  if you want to see that an anti-proton you observed at
              a balloon  altitude really came from outside of Earth,
	      you may give anti-proton as a primary, and give the 
	      balloon altitude to this. Note this is in m. 
              It's better to give the same height
	      as an observation level. DepthList is by kg/m2 so
	      you may give a negative value to this  and give the
              same value to HeightList.  
ObsPlane:     Give 0 to this. (Observation is at BorderHightH or
              BorderHightL).
KEminObs      Lower than a test particle energy.
TimeStructure T (this is to make PathLimit effective)
Trace         41 or 0. If you want to see trace, get it in Exyz system.
BackAngLimit  <-1 so that particle can go backward freely.
BorderHeightH give a large value such as 10 times of Earth radius where
	      geomagnetism becomes as week as interstellar field.
              If a test particle reach here, it is judged as escaped
	      from the earth.
HowGeoMag     2 should be given, unless the geomagnetic filed is assumed
	      to be constant. 
BorderHeightL give a value about Observation height( <= HeightOfInj).
	      If a test particle  altitude become less than this,
              it is judged as being not  escapable from the earth.    
PathLimit     a particle may make a (semi-)infinite cyclotron loop.
              To avoid this, if the total path length/beta exceeds
              this, it is judged as dead.
      
              In chookObs routine you may get id=1 o 3 (1 is escape,
              3 is capture).
++++++++++
	If you want to make a cut off table or to see a number of 
	observed anti-protons with Reverse mode, you want to input
	primary particles freely rather than by normal primary setting.
	You can do it by calling cresetPrim routine in the chookBgEvent
	routine.  
	
	call cresetPrim(aPtcl, dircos)

	where aPtcl is a /ptcl/ record and dircos is a /coord/ record.
	You must give energy, code, subcode, charge to aPtcl,
	and direction cos of a particle and direcos.sys='det', i.e.,
	the direction cos should be given in the system where x is
	directed to south, y to east, z to the vertical. Code fragment
	will be

	#include "Zptcl.h"
	#include "Zcode.h"
	
	...
	call cmkptc(aPtcl, knuc, antip, -1)  ! make anti particle
        aPtcl.fm.p(4) = energy             ! give total energy
        dircos.x = ..
	dircos.y = ..
	dircos.z = ..        
        dircos.sys ='det'            
	call cresetPrim(aPtcl, dircos)

****************
   Rigidity cut off table can be read and particles of  primary energy below
  the cut off are rejected at sampling. The relevant parameter is in
  the 1st group;
CufOffFile = ' '
  To activate this, you may give a file name (path), containing the cut off
  table. Note, the zenith angle can be given in degree or in cos value in
  the table. (In the main frame version, it should be in degree)
  A table example can be seen in Contrib/Data/Cutoff/Kamioka

***********************
In the adhoc model, the treatment of intra-nuclear cascading has been
changed so that it is the same as the main frame version.  The
purged version has some defect in the complete momentum conservation,
and somewhat complex.  The effect is, however, very small, and
would not be detected statistically.
 
----------------------------------------------------
uv1.0002
Release 1995.08.12
Event number counting is corrected. Stack size limit is reduced
to 5000 to 3000.

uv1.0001
Release 1995.08.11
Two lines in cinteraction are missing and fatal for the IMB AIX version.
(when particle is pushed, its code was wrong).  This was corrected.
Also, in the photo hadron production, there is one mistake for code setting.
Stack size limit is expanded from 2000 to 5000.

uv1.0000
Release 1995.08.08
One bug in adhoc nuclear interaction routine was removed (which gives
too large Pt to a leading particle with multiple collisions inside
a nucleus).

uv0.64560
Release 1995.08.07
The  correction of the previous version  was wrong. In all previous versions,
the user may use the results obtained for proton primaries below 500 GeV,
and for all primaries of non hadronic origin ( irrespective of energy).
The adhoc nuclear interaction routine is modified so that the incident
particle is directed to the z-axis, and later the momentum rotation is
performed.  A bug in the cross-section calculation for heavy particles are
fixed.

uv0.64474
Release 1995.08.05
There was  some fatal bug in some illconditioned cases at high energies. 
This caused higher efficiency of heavy primary showers.
Also there was one fatal bug in the fragmentation
treatment where the charge sum of fragments was incorrectly counted. The
effect at E < 500 GeV should be small.

uv0.64279
Release 1995.07.22
Bug fix.  There is a case in which an infinite loop takes place in the
event generation; the adhoc high energy nuclear interaction model
some times uses the isotropic phase space for multiparticle decay (cnbdcy.f).
If the phase space is very small, this routine goes into the infinite loop,
and Cosmos gets into such a loop once for 20000 events or so. Such events
are discarded in this version.


uv0.64064
Release 1995.07.10
csampPrimry.f cannot understand "p/n" energy sampling. (momentum/nucleon)
This is corrected.  
The bug in the skeleton-fleshing method has been detected and corrected.
The bug was due to a trick to get gaussian random numbers quickly by
Box-Master method. (Trick is that one gaussian variable at a time without minimum loss 
of speed in the Box-Masster method which produces two variables at
time).  kgauss.f is modifed so that the speed becomes slower in general.


 
uv0.64046
Release 1995.03.17
For compilers such as IBM AIX which cannot understand union/map in
the structure construct, "Zunionmap.h" is introduced to define 
the availability of UNION/MAP.  This defines UNIONMAP if union/map
conttruct can be used.  Using this, the program has been made to
be compilable by IBM type compilers.  
Important note. In UserHook, the IBM users should move chookSampleIBM.f to
chookSample.f.  Also they should move chookIBM.f to chook.f.


uv0.64016
Release 1995.03.01

One dimensional mode is supported. All particles are made to go
the same directions as the primary.  Many bugs (compiler dependent)
are removed.  In Util, new utility to draw rigidity cutoff is added.
However, rigidity cutoff itself is not incorporated into Cosmos yet.
Bugs related to the  particle going outer space still remain.
The body of cmain.f is moved to Zcmain.h and cmain.f itself is
made to include that file.


uv0.64010
Release  1995.01.13

More correct grammar.  Bug fix. Especially, for the case of a particle
going outer space. (not complete yet).


uv0.64001
Release 1994.12.26

List of un-supported stuffs.

1) Magnetic brems and pair creation
2) LPM effect
3) Muon nuclear interaction
4) Automatic  Solar Modulation and cutoff
5)  Bug: Infinite loop of charged particles in vacuum.
6) Lateral distribution of air showers and muons lateral distribution
7) QCD jet inclusion in adhoc model.
8) Pithia
9) To finish the job before specified time
10) Parallel processing
