This version contains many changes!
1) Optical photon simulation is now possible - some work still may need to be done
(e.g. the manual is not updated yet), but it should basically work already now.
2) Changes in the musrSimAna - correction of some bugs (mainly in the coincidence
of coincidence and veto detectors) and some other improvements
New variable "timeToNextEvent" added in order to simulate time differences between subsequent events.
1) /gun/meanarrivaltime meanArrivalTime (defines the mean time difference betweent
the subsequent events).
2) timeToNextEvent - new variable written out to the root tree.
This new variable is needed for the pile-up studies
Changes needed by Pavel Bakule for low energy moun beem excited by laser.
(The user can restrict a box-like region for the generated particles (muons)).
1) UPGRADE TO GEANT 4.9.3
- Physics list had been modified
- List of the physics processes in *.mac has to be modified too!
(otherwise results of 4.9.3 do not reproduce well the results
of 4.9.2).
Example *.mac files still use the old implementation of the physics
processes, i.e. they have to be corrected in future!
2) POSSIBILITY TO WRITE OUT DERIVATIVES OF THE MAGNETIC FIELD
AT A GIVEN POINT (see the documentation,
"/musr/command globalfield printFieldDerivativeAtPoint".)
Several things were added in this version:
1) varibale save_time() has been added to the root output tree
2) possibility to read in field maps, in which varibles x,y,z
increase differently than previously expected
(see the description of "variableIncreasingOrder" in the
"3DEOpera" paragraph of the documentation).
3) Added "3DEOpera" format of the fieldmap
4) Added file G4EqEMFieldWithSpin.cc_for_Geant4.9.2p02_only that
should be used only in the Geant version 4.9.2p02 (there was
a bug in this file, which is not present for any other version of Geant4)
5) Examples 101.mac and 102.mac added, but its description has not
been completed yet in the musrSim.pdf.
1) The filling of the root tree was called from musrScintSD.cc, which was
problematic, because no variables were written out if there was no
sensitive volume defined (problem for example when one wants to study
the beam-line properties using just save volumes).
Therefore the tree filling is now called from musrEventAction.cc.
2) A possibility to gently stop the run by creating a file with the
name "RUNNUMBER.stop" in the working directory has been introduced.
("Gently" means that root output file is closed properly.)
Histogram "hGeantParameters" added to the output file. This can be helpful
when more output files are merged together by "hadd" command, and info about
the number of events is needed by the analysis program.
The documentation was updated accordingly.
The reading of the field map files in the 3D Opera file format has been extended:
1) The lenght unit can also be specified in cm instead of in meters only.
2) Only one octant (in Kartesian coordinate system) of the field map can be
specified, and the field can be extrapolated to other octants (this
depends on the symmetry of the field).
3) First line of the field map does not have to be empty (but it can be).
4) Documentation has been modified accordingly.
This svn update includes several smaller corrections and updates accumulated
over last few months:
1) For the Geant4.9.2 it was necessary to remove the privately modified file
src/G4EqEMFieldWithSpin.cc. Our corrections in this file (and also in
the file src/G4DecayWithSpin.cc) were adopted by the Geant developers into
the official Geant code, and therefore these two files were deleted.
However, if one uses older version of Geant (i.e. Geant4.9.1 or older),
one should rename the G4EqEMFieldWithSpin.cc_for_Geant4.9.1_and_older in
his/her src directory to G4EqEMFieldWithSpin.cc to correct for a Geant
bug.
2) Implementation of save_polx, save_poly and save_polz variables
3) Implementation of the field map normalisation within the field map
itself (was already possible for the field-map formats generated by Toni,
now it is extended also for the field maps generated by OPERA).
4) Possibility to swap and invert x and y axis read out from the TURTLE
file.
5) Perhaps some other tiny changes
The implementation of "muIniTime" has been finalised (i.e. the time,
when the initial muons are generated). This variable is now stored
in the root tree. The documentation of the musrSim has been updated
accordingly. Simple test of the upgraded program was done,
the implementation seems to be OK.
Bug correction in "G4UserLimit":
DETAILS OF THE BUG:
Call of "G4UserLimits" was inactive in the musrSim
(using the comand "/musr/command SetUserLimits log_target 0.01")
was ignored by the simulation.
I found out, that in addition to the call of "G4UserLimits",
the "G4StepLimiter" and/or "G4UserSpecialCuts" has to be called
for a given particle (particles) that needs to be limitted. These processes
were not implemented.
I corrected the musrSim code in the svn repository. From now on,
"G4StepLimiter" should function fine, IF CALLED TOGETHER WITH SOMETHING
LIKE:
/musr/command process addProcess e- G4StepLimiter -1 -1 4
/musr/command process addProcess e+ G4StepLimiter -1 -1 4
/musr/command process addProcess mu+ G4StepLimiter -1 -1 5
More details can be found in:
http://hypernews.slac.stanford.edu/HyperNews/geant4/get/eventtrackmanage/702/1.html
and
http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/html/ch05s07.html
Added possibility to use mu- (or other particles) as the primary particles
in the G4ParticleGun (this option can be switched on by
/gun/primaryparticle ).
Few tiny modifications:
1) added doc/run file for easier processing of the musrSim.tex file
2) updated documentation (musrSim.pdf)
3) removed one of two definitions of "lightblue" in musrDetectorConstruction.cc
4) added the volume "G4Para" in musrDetectorConstruction.cc
5) corrected small bug for "2DBOperaXY" type of field in musrTabulatedElementField.cc
This is the first version of the muSR simulation code (musrSim)
based on the merged codes of Kamil Sedlak and Toni Shiroka.
It should be a running version of the simulation code, however
it has not been very well tested, therefore it will probably
need some further development.
