1 |
# |
# |
2 |
# $Id: v_100.txt,v 3.2 2002/12/05 10:17:42 pamela Exp $ |
# $Id: v_100.txt,v 3.7 2005/10/18 08:24:35 cafagna Exp $ |
3 |
# |
# |
4 |
# $Log: v_100.txt,v $ |
# $Log: v_100.txt,v $ |
5 |
|
# Revision 3.7 2005/10/18 08:24:35 cafagna |
6 |
|
# History updated |
7 |
|
# |
8 |
|
# Revision 3.6 2005/07/25 11:53:21 cafagna |
9 |
|
# Several updates. See history for details |
10 |
|
# |
11 |
|
# Revision 3.5 2004/04/06 10:33:46 pamela |
12 |
|
# NON-REPRODUCIBILITY problem of a GPAMELA RUN fixed; bug found and fixed filling in the hit structure of the calorimeter |
13 |
|
# |
14 |
|
# Revision 3.4 2003/12/17 11:32:50 pamela |
15 |
|
# CALO SIMULATION COMPLETED: geometry and special tracking parameters updated and simulation checked by a comparison with the Trieste's standalone Monte Carlo simulation |
16 |
|
# |
17 |
|
# Revision 3.3 2002/12/05 17:27:59 pamela |
18 |
|
# New GARFIELD.GAR file added and GPAMELA.FFR cleaned and updated |
19 |
|
# |
20 |
# Revision 3.2 2002/12/05 10:17:42 pamela |
# Revision 3.2 2002/12/05 10:17:42 pamela |
21 |
# Update CAS and CALO geometries and positions. Makefile updated as well |
# Update CAS and CALO geometries and positions. Makefile updated as well |
22 |
# |
# |
35 |
#CMZ : 1.00/03 30/04/96 12.23.59 by Francesco Cafagna |
#CMZ : 1.00/03 30/04/96 12.23.59 by Francesco Cafagna |
36 |
#CMZ : 1.00/02 05/04/96 15.31.25 by Francesco Cafagna |
#CMZ : 1.00/02 05/04/96 15.31.25 by Francesco Cafagna |
37 |
#CMZ : 1.00/01 28/11/95 18.51.23 by Francesco Cafagna |
#CMZ : 1.00/01 28/11/95 18.51.23 by Francesco Cafagna |
38 |
#-- Author : Francesco Cafagna 28/11/95 |
#-- Author : Francesco Cafagna 28/11/95 |
39 |
|
|
40 |
|
Nov 2005, Bari |
41 |
|
|
42 |
|
NEUTRON DETECTOR ADDED. NEW DIR: GPND |
43 |
|
|
44 |
|
The neutron detector has been added. At the moment it is just the |
45 |
|
geometry. The directory structure of the repository has been |
46 |
|
updated as well. Dimensions has been taken from picture and |
47 |
|
literature. A full upgrade to the drawing is needed. |
48 |
|
|
49 |
|
GCALOR PACKAGE ADDED. NEW DIRs: GPCALOR, GPCALORDES |
50 |
|
|
51 |
|
GCALOR package contins the CALOR simulation code and an interface |
52 |
|
to use it in GEANT. The important feature for us is the usage of |
53 |
|
the MICAP code. This is facused on the low energy neutron |
54 |
|
simulation. for details see: |
55 |
|
http://www.staff.uni-mainz.de/zeitnitz/Gcalor/gcalor.html |
56 |
|
This package should be distributed with the GEANT library but is |
57 |
|
not up to date. I did download the latest release and stored into |
58 |
|
gpcalor directory of the gpamela tree. |
59 |
|
Then I did clean up the code substituting the explicit inclusion of |
60 |
|
the commons with a #include cpp directive. In parallel I did |
61 |
|
extract the commons to include files having the same common name. I |
62 |
|
did store the include files into a newly created directory: |
63 |
|
gpcalordes. |
64 |
|
The Makefile has been updated accordingly. |
65 |
|
Please note that to avoid conflict with CRENLIB distribution the gcalor source file has been named gpcalor.F |
66 |
|
NOTE: There are still problem due to different common sizes. In |
67 |
|
particular the common MICFIL is maller in the geant library |
68 |
|
libgeant.a . There the subroutines: gmorin, gmxsec, gmplxs, are |
69 |
|
present and linked using a wrong version of the common. This still needs to be debuged. |
70 |
|
NOTE2: The auxiliary files with the cross sections: chetc.dat.gz |
71 |
|
and xsneut.dat.gz, have been added to the aux directory and moved |
72 |
|
to the working directory, i.e. GPAMELA_BIN. The GCALOR routine will |
73 |
|
look for CERN_ROOT environment variable. If found files are |
74 |
|
searched there at first, then in the working directory. A fool |
75 |
|
proof policy has to be implemented to avoid problem with |
76 |
|
synchronization fo these files. |
77 |
|
|
78 |
|
|
79 |
|
The GCALOR package |
80 |
|
May 2005, Bari |
81 |
|
|
82 |
|
Some updates on the latest modification done in the past year. |
83 |
|
|
84 |
|
NEW DATA CARD ADDED: HFSF |
85 |
|
|
86 |
|
To define a policy for the random number initial seeds |
87 |
|
definition. Using this card is possible to override GEANT seeds |
88 |
|
defined via NRDM card. The policy is selected according to the |
89 |
|
values: |
90 |
|
|
91 |
|
- 1: The seeds are initialized to the initial values found in a user |
92 |
|
defined file or the default file: INPUTSEED.DAT |
93 |
|
|
94 |
|
- 2: The seeds are initialized to the final values found in a user defined |
95 |
|
file or the default file: INPUTSEED.DAT |
96 |
|
|
97 |
|
The case 1 must be used in case the user needs to reproduce the |
98 |
|
random chain of a previous run. In this case the user can save the |
99 |
|
initial seeds, used in the run he would like to reproduce, in a |
100 |
|
binary file and pass the filename to the program using the *FLSF |
101 |
|
data card. In case the user file is not specified the default |
102 |
|
INPUTSEED.DAT will be used. |
103 |
|
|
104 |
|
The case 2 must be used in case the user needs to chain several |
105 |
|
GPAMELA run and likes to be sure he is starting the random |
106 |
|
generator using the right sequence. In this case the user must |
107 |
|
specify an input binary file using the *FLSF data card, otherwise |
108 |
|
the INPUTSEED.DAT file will be used. |
109 |
|
|
110 |
|
NEW DATA CARD ADDED: *FSFI |
111 |
|
|
112 |
|
Using this card the user can specify the logical unit and name of |
113 |
|
the file storing the initial seeds to be used to initialize the |
114 |
|
random number generator. This file must be a FORTRAN binary one |
115 |
|
storing four integer numbers. The first two are the number to be |
116 |
|
used in the case: HFSF=1, the other two will be used in the case: |
117 |
|
HFSF=2. This file can be one created by GPAMELA or by the user |
118 |
|
filled with his own seeds. For this purpose an utility program: |
119 |
|
writeseeds.f, has been added in the aux directory. In case the |
120 |
|
*FSFI card is not specified the default values: 24 and INPUTSEEDS.DAT, will |
121 |
|
be used as LUN and file name respectively. |
122 |
|
|
123 |
|
NEW DATA CARD ADDED: *LSFI |
124 |
|
|
125 |
|
Using this card the user can specify the logical unit and name of |
126 |
|
the file storing the first and last seeds used in the GPAMELA |
127 |
|
run. This file is a FORTRAN binary one. This file can be used as |
128 |
|
input one specifying it in the *FSFI data card of the next GPAMELA |
129 |
|
run. In case the *LSFI card is not specified the default values: 26 |
130 |
|
and HBOOKFILENAME.DAT (as sepified in *HFI), will be used as LUN |
131 |
|
and file name respectively. |
132 |
|
|
133 |
|
NEW UTILITY PROGRAMS ADDED: writeseeds.f, readseeds.f |
134 |
|
|
135 |
|
These new programs have been added in the aux directory. Using these a |
136 |
|
user defined seed file can be created and re-read. |
137 |
|
|
138 |
|
NEW VOLUMES ADDED: MSHE, BSPH; PRESSURIZED CONTAINER ADDED |
139 |
|
|
140 |
|
Alexey Bakaldin, in MEPHI, did add the PAMELA pressurized container to |
141 |
|
the simulation. He did defined new volumes filled with aluminum and |
142 |
|
placed inside the mother volume. Positions have been fine tuned by |
143 |
|
Marialuigia Ambriola and compared to the CAD drawings. |
144 |
|
Two new volumes have been added to simulate the container: |
145 |
|
- MSHE, a tube simulating the middle part of the container |
146 |
|
- BSPH, the spherical bottom part of the container |
147 |
|
|
148 |
|
To better simulate the upper part the SHEL volume has been modified |
149 |
|
into a cone. Dimentions of the top cover: TSPH, have been modified |
150 |
|
accordingly. |
151 |
|
|
152 |
|
DETECTOR POSITIONS REVIEWED |
153 |
|
|
154 |
|
All detector Z positions have been reviewd to fit into the |
155 |
|
simulated pressurized container. |
156 |
|
|
157 |
|
TRD GEOMETRY AND CALIBRATION REVIEWD |
158 |
|
|
159 |
|
The TRD geometry has been deeply reviewed. Using the CAD drawings |
160 |
|
the carbon fiber frames have been simulated and radiator dimentions |
161 |
|
corrected. For this reason the calibration done on the beam tests |
162 |
|
has been revied and new sets of calibration constants calculated |
163 |
|
comparing the beam test data with the GPAMELA results. The new |
164 |
|
constants are about 3% larger than the previous ones. |
165 |
|
|
166 |
|
TRACKER GEOMETRY REVIEWED. NEW VOLUME DEFINED: THBP, TPAS, TPAI |
167 |
|
|
168 |
|
Thanks to Lorenzo Bonechi for the drawings and explanations. Now the |
169 |
|
hybrd cards have been put into the simulation and the geometry updated |
170 |
|
considering the dead zones in the silicon detectors. The hybrid zone |
171 |
|
has been simulated as well. At the moment the hybrid is simulated as |
172 |
|
a G10 plates. The full height of the tracker magnet has been |
173 |
|
reviewed as well. |
174 |
|
|
175 |
|
The tracker ladder is now simulated inside a nitrogen box: TPAS, |
176 |
|
placed inside an aluminum frame: TRPB. Each silicon ladder has been |
177 |
|
simulated using two silicon blocks: TRSL, into each of this block a |
178 |
|
smaller silicon detector: TPAI, has been placed inside the larger |
179 |
|
silicon block TRSL. In this way the subdivided silicon ladder can |
180 |
|
be upgraded with an indipendend roto-translation for each sensor. |
181 |
|
|
182 |
|
The TRPB aluminum frame has been enlarged to fit the external |
183 |
|
magnet canister frame. |
184 |
|
|
185 |
|
The last plane has been flipped with a 180 degree rotation around |
186 |
|
the X axis. |
187 |
|
|
188 |
|
TRACKER HIT STRUCTURE REVIEWED |
189 |
|
|
190 |
|
Taking into account the new version of the tracker geometry, the hit |
191 |
|
structure for this detector has been revied. |
192 |
|
|
193 |
|
CALORIMETER GEOMETRY REVIEWED |
194 |
|
|
195 |
|
Marco Albi reviewed the calorimeter dimentions and positioning. |
196 |
|
|
197 |
|
|
198 |
|
29 March 2004, Bari |
199 |
|
|
200 |
|
NON-REPRODUCIBILITY PROBLEM OF A GPAMELA RUN FIXED. |
201 |
|
The non-reproducibility of a GPAMELA run was due to the random number |
202 |
|
initialization in the GARFIELD code. In GARFIELD by default, the initial |
203 |
|
seeds of the random number generators are always the same while the random |
204 |
|
number generators are called a given number of times (determined by the |
205 |
|
hour of the day) during the initialization phase (see init.f subroutine in |
206 |
|
the GARFIELD code for details). Follows that different runs produce |
207 |
|
different results without changing the initial seeds. To have identical |
208 |
|
results in different runs, the GARFIELD program has to start typing the |
209 |
|
noRNDM_initialisation switch. To avoid of specifying this switch |
210 |
|
by the user, |
211 |
|
the GARFIELD package has been upgraded with a patch. In this way the problem |
212 |
|
is partially solved because, now, the initial seeds of the random generators |
213 |
|
in GARFIELD will be always the same even if the RNDM GEANT data card is |
214 |
|
activated by the user for changing the initial seeds in the GPAMELA program. |
215 |
|
Work is in progress for a more general correction of this problem. |
216 |
|
Please, use the updated GARFIELD code released with the CVS version v4r1 |
217 |
|
to fix this problem. |
218 |
|
|
219 |
|
|
220 |
|
RNDM ROUTINE REPLACED BY THE GRNDM ROUTINE IN GPXTR AND NPOISS. |
221 |
|
The obsolete RNDM random number generator has been replaced by the GEANT |
222 |
|
GRNDN routine in the gpxtr.F subroutine and in the npoiss.F function. |
223 |
|
|
224 |
|
BUG FOUND AND FIXED: the set and detector calorimeter addresses (ISCAL |
225 |
|
and IDCASI variables) used in GUTREV were respectively set to a fixed |
226 |
|
values of 12 and 1. The correct values of these variables are stored in |
227 |
|
the GPSED common when the set and the detector ZEBRA banks are filled |
228 |
|
during a run. In general the values of the set and detector addresses |
229 |
|
depend on the number of active detectors in a given run. ISCAL=12 and |
230 |
|
IDCASI=1 are only right when all the detectors of GPAMELA are active. |
231 |
|
|
232 |
|
9 December 2003, Bari |
233 |
|
|
234 |
|
CALORIMETER SIMULATION completed! The update of the geometry and of the |
235 |
|
special tracking parameters and the tuning of the calorimeter have been |
236 |
|
successfully done. A great quantity of simulated data have been produced |
237 |
|
in the calorimeter for different particles (muons, electrons and pions) |
238 |
|
and momenta (5 and 40 GeV/c) and the output data have been analyzed. The |
239 |
|
distributions of the total energy deposited in the calorimeter and the |
240 |
|
total number of strips hit have been compared with the respective |
241 |
|
distributions produced by the Trieste's tuned standalone Monte Carlo |
242 |
|
simulation program of the PAMELA calorimeter. The accord between the |
243 |
|
two simulations is excellent. Many thanks to Mirko for his collaboration. |
244 |
|
|
245 |
|
Working in progress on TRD. The GARFIELD interface to the HEED program is not |
246 |
|
optimized to track particle with a charge greater than one and photons. The |
247 |
|
program print a warning message to advise the user when it is the case. |
248 |
|
|
249 |
|
18 April 2003, Bari |
250 |
|
|
251 |
|
The buffer size of each column of the GPAMELA Ntuple has been increased to |
252 |
|
4096 and set equal to the record length, defined by a call to the HROPEN |
253 |
|
routine. |
254 |
|
Also the length of the common /PAWC/ (parameter NWPAW) has been increased |
255 |
|
to 1.34E8, according to the rule that it has to be larger than the number |
256 |
|
of columns times the buffer size. |
257 |
|
|
258 |
|
10 April 2003, Bari |
259 |
|
|
260 |
|
The variables in the HIT STRUCTURE of the CALORIMETER and their way to be |
261 |
|
filled have been changed according to the electronics system of the real |
262 |
|
detector. In fact, because each silicon detector (module) consists of |
263 |
|
32 strips and each strip is connected to those belonging to the two detectors |
264 |
|
of the same row (or column) for forming 24 cm long strips, the sum of the |
265 |
|
deposited energies in the strips forming a `long strip' is now calculated for |
266 |
|
each event (gpucal.F subroutine) and it is stored in a hit only at the |
267 |
|
end of the event (gutrev.F subroutine). |
268 |
|
The output variables of the GPAMELA en-tuple are then filled in the vectors |
269 |
|
ICAPLANE(NTHCAL), ICASTRIP(NTHCAL), ENESTRIP(NTHCAL) and ICAMOD(NTHCAL), |
270 |
|
by a call to the GPDCAL subroutine: |
271 |
|
-ICAPLANE(i) contains the number of hit plane; |
272 |
|
-ICASTRIP(i) contains the number of hit strip; |
273 |
|
-ICAMOD(i) can assume different values based on the number of times and |
274 |
|
positions in which a `long strip' has been hit. |
275 |
|
-ENESTRIP(i) contains the deposited energy in the hit strip; |
276 |
|
where i is the number of hit (1<i<4224). |
277 |
|
Note that in the calorimeter each hit is filled at the end of the event and |
278 |
|
that there is a hit for each `long strip' hit from |
279 |
|
the particle. This use of the hit structure is different for the other |
280 |
|
detectors and it has been considered to avoid a too big number of hit in the |
281 |
|
calorimeter due to the showers. Follows that NTHCAL, which is the |
282 |
|
max number of hit in the calorimeter, is equal to 4224, the total |
283 |
|
number of `long strips'. So, for each event, the real number of hit will |
284 |
|
be less or equal to 4224. |
285 |
|
ICAMOD(i) is an additional information that does not exist in the real |
286 |
|
detector: if the strip i (i=1,32) of the module 1 or 2 or 3 |
287 |
|
is hit, the value of ICAMOD(i) is respectively incremented of 1, 100, 10000. |
288 |
|
Analogously it is done, if it is the strip j (j=33,64) of the modules 4, 5 |
289 |
|
and 6 or if it is the strip k (k=65,96) of the modules 7, 8 and 9. |
290 |
|
For example if we consider the hit 1 of an event, we could read: |
291 |
|
ICASTRIP(1)=30, ICAPLANE(1)=21, ENESTRIP(1)=0.5E-03 and ICAMOD(1)=10001. |
292 |
|
It means that the hit 1 contains the information that in the strip 30 of the |
293 |
|
plane 21 has been deposited a total energy of 0.5E-03 GeV. In addition the |
294 |
|
`long strip 30' has been hit two times, one in the first module and the |
295 |
|
other in the third one. |
296 |
|
|
297 |
|
The energy deposited in the calorimeter is calculated in GeV. |
298 |
|
|
299 |
|
To store the hits in the calorimeter the subroutine GSAHIT is used instead of |
300 |
|
GSCHIT. |
301 |
|
|
302 |
|
To retrieve the hit structure the call to the routine GPRHIT is done instead |
303 |
|
of a call to the GFHITS subroutine. |
304 |
|
|
305 |
|
25 February 2003, Bari |
306 |
|
|
307 |
|
BUG found: |
308 |
|
DCUTEAER, DCUTEAL, DCUTECE, DCUTECP, DCUTEFE, DCUTEG10C, DCUTEG10, DCUTEKAP, |
309 |
|
DCUTEN2G, DCUTEROA, DCUTESCIN, DCUTESICA, DCUTETRAD, DCUTEW2, |
310 |
|
DCUTEW, DCUTEXE variables missed in the commons: gpaer.inc, gpal.inc, gpce.inc, |
311 |
|
gpcp.inc, gpfe.inc, gpg10c.inc, gpg10.inc, gpkap.inc, gpn2g.inc, gproa.inc, |
312 |
|
gpscin.inc (obsolete), gpscint.inc, gpsica.inc, gptrad.inc, gpw2.inc, gpw.inc, |
313 |
|
gpxe.inc, gpdaer.inc, gpdal.inc, gpdce.inc, gpdcp.inc, gpdfe.inc, gpdg10c.inc, |
314 |
|
gpdg10.inc, gpdkap.inc, gpdn2g.inc, gpdroa.inc, gpdscin.inc, gpdsica.inc, |
315 |
|
gpdtrad.inc, gpdw2.inc, gpdw.inc, gpdxe.inc. |
316 |
|
They have been added in these commons and they have been initialized in the |
317 |
|
GPSTM subroutine. |
318 |
|
|
319 |
|
Updated the special tracking parameters SICALO, TUNGA, KAOLINITE and G10C |
320 |
|
in the subroutines gpsica.F, gpw2.F, gpw.F, gpce.F and gpg10c.F. They were |
321 |
|
suggested by Mirko Boezio. |
322 |
|
|
323 |
|
Updated the value of the absorption length for silicon in the calorimeter |
324 |
|
and tracker although this parameter is ignored by GEANT. For this reason |
325 |
|
it was equal to the radiation length. |
326 |
|
|
327 |
|
Updated the relative positions of the calorimeter planes. The corrected |
328 |
|
shifting are: |
329 |
|
|
330 |
|
first view: (Dxo,Dyo)=(0.10,0.05) cm |
331 |
|
second view: (Dxo,Dyo)=(-0.05,0.10) cm |
332 |
|
third view: (Dxo,Dyo)=(-0.10,-0.05) cm |
333 |
|
fourth view: (Dxo,Dyo)=(0.05,-0.10) cm |
334 |
|
|
335 |
4 November 2002, Bari |
4 November 2002, Bari |
336 |
|
|
337 |
CAS detectors distances modified |
CAS detectors distances modified |
338 |
|
|
339 |
The distances between the CAS detectors have been modified based on the |
The distances between the CAS detectors have been modified based on the |
340 |
latest CAD drawings. |
latest CAD drawings. |
341 |
|
|
342 |
2 November 2002, Bari |
2 November 2002, Bari |
343 |
|
|
344 |
CALORIMETER geometry upgrade |
CALORIMETER geometry upgrade |
345 |
|
|
346 |
The volumes CAPD and CAAD have been taken off from the calorimeter. |
The volumes CAPD and CAAD have been taken off from the calorimeter. |
347 |
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 |
348 |
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, |
349 |
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 |
350 |
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, |
351 |
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 |
352 |
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 |
353 |
dimensions of some volumes have been upgraded, including the external ones: |
dimensions of some volumes have been upgraded, including the external ones: |
354 |
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, |
355 |
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 |
356 |
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 |
357 |
a reliable description of the event in the S4 scintillator. |
a reliable description of the event in the S4 scintillator. |
358 |
|
|
359 |
22 October 2002, Stockholm |
22 October 2002, Stockholm |
360 |
|
|
471 |
|
|
472 |
TRD IONIZATION ENERGY LOSS GENERATED NOW BY GARFIELD |
TRD IONIZATION ENERGY LOSS GENERATED NOW BY GARFIELD |
473 |
To generate the ionization in the TRD straw tubes the HEED program |
To generate the ionization in the TRD straw tubes the HEED program |
474 |
interfaced by GARFIELD is used (GEANT does not simulate the ionization |
interfaced by GARFIELD is used (GEANT does not correctly simulate |
475 |
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 |
476 |
the particle in the gas and then passes the coordinates, translated in |
tracks the particle in the gas and then passes the coordinates, |
477 |
the DRS, to GARFIELD. The GARFIELD subroutines are called by GPUTRD. |
translated in the DRS, to GARFIELD. The GARFIELD subroutines are |
478 |
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 |
479 |
variables EGARTRD and NGARTRD of the CWN-tplu. |
are stored in the variables EGARTRD and NGARTRD of the CWN-tplu. |
480 |
|
|
481 |
1 May 2001, Bari |
1 May 2001, Bari |
482 |
|
|
555 |
The definition of the ITRSO detector has been changed in the GPSED routine: |
The definition of the ITRSO detector has been changed in the GPSED routine: |
556 |
NVTRD has been forced to 2 for compatibility with GPDTRD. |
NVTRD has been forced to 2 for compatibility with GPDTRD. |
557 |
|
|
|
3 april 2001, Bari |
|
|
|
|
|
|
|
558 |
28 march 2001, Bari |
28 march 2001, Bari |
559 |
|
|
560 |
ITRSO has been defined as a sensitive detector in GSTMED routine and it has |
ITRSO has been defined as a sensitive detector in GSTMED routine and it has |