--- gpamela/history/v_100.txt 2002/07/11 16:01:59 3.1.1.1 +++ gpamela/history/v_100.txt 2004/04/06 10:33:46 3.5 @@ -1,7 +1,19 @@ # -# $Id$ +# $Id: v_100.txt,v 3.4 2003/12/17 11:32:50 pamela Exp $ +# +# $Log: v_100.txt,v $ +# Revision 3.4 2003/12/17 11:32:50 pamela +# CALO SIMULATION COMPLETED: geometry and special tracking parameters updated and simulation checked by a comparison with the Trieste's standalone Monte Carlo simulation +# +# Revision 3.3 2002/12/05 17:27:59 pamela +# New GARFIELD.GAR file added and GPAMELA.FFR cleaned and updated +# +# Revision 3.2 2002/12/05 10:17:42 pamela +# Update CAS and CALO geometries and positions. Makefile updated as well +# +# Revision 3.1.1.1 2002/07/11 16:01:59 cafagna +# First GPAMELA release on CVS # -# $Log$ # #CMZ : 3.00/00 11/02/2002 20.05.23 by Unknown #CMZ : 2.03/00 06/11/2000 02.14.56 by Francesco Cafagna @@ -14,7 +26,182 @@ #CMZ : 1.00/03 30/04/96 12.23.59 by Francesco Cafagna #CMZ : 1.00/02 05/04/96 15.31.25 by Francesco Cafagna #CMZ : 1.00/01 28/11/95 18.51.23 by Francesco Cafagna -#-- Author : Francesco Cafagna 28/11/95 +#-- Author : Francesco Cafagna 28/11/95 + +29 March 2004, Bari + +NON-REPRODUCIBILITY PROBLEM OF A GPAMELA RUN FIXED. +The non-reproducibility of a GPAMELA run was due to the random number +initialization in the GARFIELD code. In GARFIELD by default, the initial +seeds of the random number generators are always the same while the random +number generators are called a given number of times (determined by the +hour of the day) during the initialization phase (see init.f subroutine in +the GARFIELD code for details). Follows that different runs produce +different results without changing the initial seeds. To have identical +results in different runs, the GARFIELD program has to start typing the +noRNDM_initialisation switch. To avoid of specifying this switch by the user, +the GARFIELD package has been upgraded with a patch. In this way the problem +is partially solved because, now, the initial seeds of the random generators +in GARFIELD will be always the same even if the RNDM GEANT data card is +activated by the user for changing the initial seeds in the GPAMELA program. +Work is in progress for a more general correction of this problem. +Please, use the updated GARFIELD code released with the CVS version v4r1 +to fix this problem. + + +RNDM ROUTINE REPLACED BY THE GRNDM ROUTINE IN GPXTR AND NPOISS. +The obsolete RNDM random number generator has been replaced by the GEANT +GRNDN routine in the gpxtr.F subroutine and in the npoiss.F function. + +BUG FOUND AND FIXED: the set and detector calorimeter addresses (ISCAL +and IDCASI variables) used in GUTREV were respectively set to a fixed +values of 12 and 1. The correct values of these variables are stored in +the GPSED common when the set and the detector ZEBRA banks are filled +during a run. In general the values of the set and detector addresses +depend on the number of active detectors in a given run. ISCAL=12 and +IDCASI=1 are only right when all the detectors of GPAMELA are active. + +9 December 2003, Bari + +CALORIMETER SIMULATION completed! The update of the geometry and of the +special tracking parameters and the tuning of the calorimeter have been +successfully done. A great quantity of simulated data have been produced +in the calorimeter for different particles (muons, electrons and pions) +and momenta (5 and 40 GeV/c) and the output data have been analyzed. The +distributions of the total energy deposited in the calorimeter and the +total number of strips hit have been compared with the respective +distributions produced by the Trieste's tuned standalone Monte Carlo +simulation program of the PAMELA calorimeter. The accord between the +two simulations is excellent. Many thanks to Mirko for his collaboration. + +Working in progress on TRD. The GARFIELD interface to the HEED program is not +optimized to track particle with a charge greater than one and photons. The +program print a warning message to advise the user when it is the case. + +18 April 2003, Bari + +The buffer size of each column of the GPAMELA Ntuple has been increased to +4096 and set equal to the record length, defined by a call to the HROPEN +routine. +Also the length of the common /PAWC/ (parameter NWPAW) has been increased +to 1.34E8, according to the rule that it has to be larger than the number +of columns times the buffer size. + +10 April 2003, Bari + +The variables in the HIT STRUCTURE of the CALORIMETER and their way to be +filled have been changed according to the electronics system of the real +detector. In fact, because each silicon detector (module) consists of +32 strips and each strip is connected to those belonging to the two detectors +of the same row (or column) for forming 24 cm long strips, the sum of the +deposited energies in the strips forming a `long strip' is now calculated for +each event (gpucal.F subroutine) and it is stored in a hit only at the +end of the event (gutrev.F subroutine). +The output variables of the GPAMELA en-tuple are then filled in the vectors +ICAPLANE(NTHCAL), ICASTRIP(NTHCAL), ENESTRIP(NTHCAL) and ICAMOD(NTHCAL), +by a call to the GPDCAL subroutine: +-ICAPLANE(i) contains the number of hit plane; +-ICASTRIP(i) contains the number of hit strip; +-ICAMOD(i) can assume different values based on the number of times and + positions in which a `long strip' has been hit. +-ENESTRIP(i) contains the deposited energy in the hit strip; +where i is the number of hit (1