/[PAMELA software]/gpamela/history/v_100.txt

Diff of /gpamela/history/v_100.txt

Parent Directory | Revision Log | View Patch Patch

-revision 3.2 by pamela,
Thu Dec  5 10:17:42 2002 UTC
+revision 3.6 by cafagna,
Mon Jul 25 11:53:21 2005 UTC
 Line 1
  #
- # $Id: v_100.txt,v 3.1.1.1 2002/07/11 16:01:59 cafagna Exp $
+ # $Id: v_100.txt,v 3.5 2004/04/06 10:33:46 pamela Exp $
  #
  # $Log: v_100.txt,v $
+ # Revision 3.5  2004/04/06 10:33:46  pamela
+ # NON-REPRODUCIBILITY problem of a GPAMELA RUN fixed; bug found and fixed filling in the hit structure of the calorimeter
+ #
+ # 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
  #
-Line 17
+Line 29
  #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
+ May 2005, Bari
+ Some updates on the latest modification done in the past year.
+ NEW DATA CARD ADDED: HFSF
+    To define a policy for the random number initial seeds
+    definition. Using this card is possible to override GEANT seeds
+    defined via NRDM card. The policy is selected according to the
+    values:
+    - 1: The seeds are initialized to the initial values found in a user
+         defined file or the default file: INPUTSEED.DAT
+    - 2: The seeds are initialized to the final values found in a user defined
+         file or the default file: INPUTSEED.DAT
+    The case 1 must be used in case the user needs to reproduce the
+    random chain of a previous run. In this case the user can save the
+    initial seeds, used in the run he would like to reproduce, in a
+    binary file and pass the filename to the program using the *FLSF
+    data card. In case the user file is not specified the default
+    INPUTSEED.DAT will be used.
+    The case 2 must be used in case the user needs to chain several
+    GPAMELA run and likes to be sure he is starting the random
+    generator using the right sequence. In this case the user must
+    specify an input binary file using the *FLSF data card, otherwise
+    the INPUTSEED.DAT file will be used.
+ NEW DATA CARD ADDED: *FSFI
+    Using this card the user can specify the logical unit and name of
+    the file storing the initial seeds to be used to initialize the
+    random number generator. This file must be a FORTRAN binary one
+    storing four integer numbers. The first two are the number to be
+    used in the case: HFSF=1, the other two will be used in the case:
+    HFSF=2. This file can be one created by GPAMELA or by the user
+    filled with his own seeds. For this purpose an utility program:
+    writeseeds.f, has been added in the aux directory.  In case the
+    *FSFI card is not specified the default values: 24 and INPUTSEEDS.DAT, will
+    be used as LUN and file name respectively.
+ NEW DATA CARD ADDED: *LSFI
+    Using this card the user can specify the logical unit and name of
+    the file storing the first and last seeds used in the GPAMELA
+    run. This file is a FORTRAN binary one. This file can be used as
+    input one specifying it in the *FSFI data card of the next GPAMELA
+    run.  In case the *LSFI card is not specified the default values: 26
+    and OUTPUTSEEDS.DAT, will be used as LUN and file name respectively.
+ NEW UTILITY PROGRAMS ADDED: writeseeds.f, readseeds.f
+    These new programs have been added in the aux directory. Using these a
+    user defined seed file can be created and re-read.
+ NEW VOLUMES ADDED: MSHE, BSPH; PRESSURIZED CONTAINER ADDED
+    Alexey Bakaldin, in MEPHI, did add the PAMELA pressurized container to
+    the simulation. He did defined new volumes filled with aluminum and
+    placed inside the mother volume. Positions have been fine tuned by
+    Marialuigia Ambriola and compared to the CAD drawings.
+    Two new volumes have been added to simulate the container:
+    - MSHE, a tube simulating the middle part of the container
+    - BSPH, the spherical bottom part of the container
+    To better simulate the upper part the SHEL volume has been modified
+    into a cone. Dimentions of the top cover: TSPH, have been modified
+    accordingly.
+ DETECTOR POSITIONS REVIEWED
+    All detector Z positions have been reviewd to fit into the
+    simulated pressurized container.
+ TRD GEOMETRY AND CALIBRATION REVIEWD
+    The TRD geometry has been deeply reviewed. Using the CAD drawings
+    the carbon fiber frames have been simulated and radiator dimentions
+    corrected. For this reason the calibration done on the beam tests
+    has been revied and new sets of calibration constants calculated
+    comparing the beam test data with the GPAMELA results. The new
+    constants are about 3% larger than the previous ones.
+ TRACKER GEOMETRY REVIEWED. NEW VOLUME DEFINED: THBP, TPAS, TPAI
+    Thanks to Lorenzo Bonechi for the drawings and explanations. Now the
+    hybrd cards have been put into the simulation and the geometry updated
+    considering the dead zones in the silicon detectors. The hybrid zone
+    has been simulated as well. At the moment the hybrid is simulated as
+    a G10 plates. The full height of the tracker magnet has been
+    reviewed as well.
+    The tracker ladder is now simulated inside a nitrogen box: TPAS,
+    placed inside an aluminum frame: TRPB. Each silicon ladder has been
+    simulated using two silicon blocks: TRSL, into each of this block a
+    smaller silicon detector: TPAI, has been placed inside the larger
+    silicon block TRSL. In this way the subdivided silicon ladder can
+    be upgraded with an indipendend roto-translation for each sensor.
+    The TRPB aluminum frame has been enlarged to fit the external
+    magnet canister frame.
+    The last plane has been flipped with a 180 degree rotation around
+    the X axis.
+ TRACKER HIT STRUCTURE REVIEWED
+    Taking into account the new version of the tracker geometry, the hit
+    structure for this detector has been revied.
+ CALORIMETER GEOMETRY REVIEWED
+    Marco Albi reviewd the calorimeter dimentions and positioning.
+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.
+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.
+April 2003, Bari
+    The buffer size of each column of the GPAMELA Ntuple has been increased to
+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.
+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
+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<i<4224).
+    Note that in the calorimeter each hit is filled at the end of the event and
+    that there is a hit for each `long strip' hit from
+    the particle. This use of the hit structure is different for the other
+    detectors and it has been considered to avoid a too big number of hit in the
+    calorimeter due to the showers. Follows that NTHCAL, which is the
+    max number of hit in the calorimeter, is equal to 4224, the total
+    number of `long strips'. So, for each event, the real number of hit will
+    be less or equal to 4224.
+    ICAMOD(i) is an additional information that does not exist in the real
+    detector: if the strip i (i=1,32) of the module 1 or 2 or 3
+    is hit, the value of ICAMOD(i) is respectively incremented of 1, 100, 10000.
+    Analogously it is done, if it is the strip j (j=33,64) of the modules 4, 5
+    and 6 or if it is the strip k (k=65,96) of the modules 7, 8 and 9.
+    For example if we consider the hit 1 of an event, we could read:
+    ICASTRIP(1)=30, ICAPLANE(1)=21, ENESTRIP(1)=0.5E-03 and ICAMOD(1)=10001.
+    It means that the hit 1 contains the information that in the strip 30 of the
+    plane 21 has been deposited a total energy of 0.5E-03 GeV. In addition the
+    `long strip 30' has been hit two times, one in the first module and the
+    other in the third one.
+    The energy deposited in the calorimeter is calculated in GeV.
+    To store the hits in the calorimeter the subroutine GSAHIT is used instead of
+    GSCHIT.
+    To retrieve the hit structure the call to the routine GPRHIT is done instead
+    of a call to the GFHITS subroutine.
+February 2003, Bari
+ BUG found:
+    DCUTEAER, DCUTEAL, DCUTECE, DCUTECP, DCUTEFE, DCUTEG10C, DCUTEG10, DCUTEKAP,
+    DCUTEN2G, DCUTEROA, DCUTESCIN, DCUTESICA, DCUTETRAD, DCUTEW2,
+    DCUTEW, DCUTEXE variables missed in the commons: gpaer.inc, gpal.inc, gpce.inc,
+    gpcp.inc, gpfe.inc, gpg10c.inc, gpg10.inc, gpkap.inc, gpn2g.inc, gproa.inc,
+    gpscin.inc (obsolete), gpscint.inc, gpsica.inc, gptrad.inc, gpw2.inc, gpw.inc,
+    gpxe.inc, gpdaer.inc, gpdal.inc, gpdce.inc, gpdcp.inc, gpdfe.inc, gpdg10c.inc,
+    gpdg10.inc, gpdkap.inc, gpdn2g.inc, gpdroa.inc, gpdscin.inc, gpdsica.inc,
+    gpdtrad.inc, gpdw2.inc, gpdw.inc, gpdxe.inc.
+    They have been added in these commons and they have been initialized in the
+    GPSTM subroutine.
+    Updated the special tracking parameters SICALO, TUNGA, KAOLINITE and G10C
+    in the subroutines gpsica.F, gpw2.F, gpw.F, gpce.F and gpg10c.F. They were
+    suggested by Mirko Boezio.
+    Updated the value of the absorption length for silicon in the calorimeter
+    and tracker although this parameter is ignored by GEANT. For this reason
+    it was equal to the radiation length.
+    Updated the relative positions of the calorimeter planes. The corrected
+    shifting are:
+    first view: (Dxo,Dyo)=(0.10,0.05) cm
+    second view: (Dxo,Dyo)=(-0.05,0.10) cm
+    third view: (Dxo,Dyo)=(-0.10,-0.05) cm
+    fourth view: (Dxo,Dyo)=(0.05,-0.10) cm
 November 2002, Bari
  CAS detectors distances modified
- The distances between the CAS detectors has been modified based on the
+    The distances between the CAS detectors have been modified based on the
- latest CAD drawings.
+    latest CAD drawings.
 November 2002, Bari
  CALORIMETER geometry upgrade
- The volumes CAPD and CAAD have been taken off from the calorimeter.
+    The volumes CAPD and CAAD have been taken off from the calorimeter.
- In addition the logical tree has been slightly changed to make the shifts of
+    In addition the logical tree has been slightly changed to make the shifts of
- the silicon planes into the calorimeter box easier, i.e. the CAPL volume,
+    the silicon planes into the calorimeter box easier, i.e. the CAPL volume,
- which was made of the CASI, CAKP, CAGL, C10C and CAKA volumes, has
+    which was made of the CASI, CAKP, CAGL, C10C and CAKA volumes, has
- been split up in the volumes CANS and CAPL. Now CANS is made of the CAKP,
+    been split up in the volumes CANS and CAPL. Now CANS is made of the CAKP,
- CAGL, C10C and CAKA volumes while CAPL contains the CASI volume, that has to
+    CAGL, C10C and CAKA volumes while CAPL contains the CASI volume, that has to
- be shifted as a function of the vertical position in the calorimeter. Also the
+    be shifted as a function of the vertical position in the calorimeter. Also the
- dimensions of some volumes have been upgraded, including the external ones:
+    dimensions of some volumes have been upgraded, including the external ones:
- CALB and CALS. CALS is an aluminum box of dimensions: 48.4*48.4*21.278 cm^3,
+    CALB and CALS. CALS is an aluminum box of dimensions: 48.4*48.4*21.278 cm^3,
- having side-walls 1 cm thick and a bottom of 1 mm. The real box is more
+    having side-walls 1 cm thick and a bottom of 1 mm. The real box is more
- complicated and the configuration of the bottom should be upgraded if we want
+    complicated and the configuration of the bottom should be upgraded if we want
- a reliable description of the event in the S4 scintillator.
+    a reliable description of the event in the S4 scintillator.
 October 2002, Stockholm
-Line 158 
 TRACK COMMAND CALLED BY GPGARIN
+Line 424 
 TRACK COMMAND CALLED BY GPGARIN
  TRD IONIZATION ENERGY LOSS GENERATED NOW BY GARFIELD
     To generate the ionization in the TRD straw tubes the HEED program
-    interfaced by GARFIELD is used (GEANT does not simulate the ionization
+    interfaced by GARFIELD is used (GEANT does not correctly simulate
-    in thin layer and in the gas, correctly). The idea is that GEANT tracks
+    the ionization in thin layer and in the gas). The idea is that GEANT
-    the particle in the gas and then passes the coordinates, translated in
+    tracks the particle in the gas and then passes the coordinates,
-    the DRS, to GARFIELD. The GARFIELD subroutines are called by GPUTRD.
+    translated in the DRS, to GARFIELD. The GARFIELD subroutines are
-    The energy loss and the number of clusters in TRD are stored in the
+    called by GPUTRD. The energy loss and the number of clusters in TRD
-    variables EGARTRD and NGARTRD of the CWN-tplu.
+    are stored in the variables EGARTRD and NGARTRD of the CWN-tplu.
 May 2001, Bari
-Line 242 
 NEW SEQUENCES ADDED: $XPRINTPLOT,$PRINTP
+Line 508 
 NEW SEQUENCES ADDED: $XPRINTPLOT,$PRINTP
     The definition of the ITRSO detector has been changed in the GPSED routine:
     NVTRD has been forced to 2 for compatibility with GPDTRD.
-april 2001, Bari
 march 2001, Bari
     ITRSO has been defined as a sensitive detector in GSTMED routine and it has

 Legend:



Removed from v.3.2
 


changed lines


 
Added in v.3.6
 Legend:



Removed from v.3.2
 


changed lines


 
Added in v.3.6
-Removed from v.3.2
+Added in v.3.6

	ViewVC Help
Powered by ViewVC 1.1.23