From: Jens Ivar Jordre (jensivar.jordre@fi.uib.no)
Date: Tue Apr 29 2003 - 18:17:57 EDT
Howdy.
I have a problem with the latest version of BRAG for which other more
experienced Fortran programmers may have a solution. If you don't like
Fortran details, you are welcome to skip the rest of this mail.
I've attached a minimalistic kumac. All this kumac does is to set fms1,
fms2, t1 and t2 and open a file. But the context in which I discovered
the problem was a "regular" simulation run.
When running this kumac and looking at the content of the cdat file
using e.g. "hexdump -c foobar.cdat | less", I get something like:
0000000 352 003 \0 \0 032 \0 \0 \0 G 247 306 > 002 362 k 277
0000010 ^ 271 K 300 \0 \0 200 277 \0 \0 \0 \0 \0 \0 \0 \0
0000020 \0 \0 372 301 \0 \0 200 ? \0 \0 \0 \0 \0 \0 \0 \0
0000030 \0 \0 372 301 \0 \0 \0 \0 ' 306 227 = 314 377 021 264
0000040 313 K 177 ? f f 206 A f f 036 A \0 \0 340 A
0000050 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000070 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 003 \0 \0 \0
0000080 T 2 ! 303 217 302 \0 \0 \0 \0 223 K D
0000090 323 206 ~ ? 211 F \a 264 345 g 333 275 \0 \0 \0 \0
00000a0 \0 \0 200 ? \0 \0 \0 \0 336 g 333 = 314 377 021 264
00000b0 325 206 ~ ? f f 236 A f f 036 A \0 \0 027 B
00000c0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
...(etc)...
To match the BrGeantInput::ReadStreamHeader() line 2 should instead be
analogous to the line starting with 0000080, i.e line 9 above. Here it
sais "T 2 ", indicating detector T2.
The curious things is that if I disable fms2 in the kumac the output is
(I guess) the way it should be:
0000000 352 003 \0 \0 021 \0 \0 \0 001 \0 \0 \0 003 \0 \0 \0
0000010 T 1 n 271 302 \0 \0 \0 \0 | 331 372 C
0000020 311 K 177 ? 211 F \a 264 2 306 227 275 \0 \0 \0 \0
0000030 \0 \0 200 ? \0 \0 \0 \0 ' 306 227 = 314 377 021 264
0000040 313 K 177 ? f f 206 A f f 036 A \0 \0 340 A
0000050 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000070 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 003 \0 \0 \0
0000080 T 2 ! 303 217 302 \0 \0 \0 \0 223 K D
0000090 323 206 ~ ? 211 F \a 264 345 g 333 275 \0 \0 \0 \0
00000a0 \0 \0 200 ? \0 \0 \0 \0 336 g 333 = 314 377 021 264
00000b0 325 206 ~ ? f f 236 A f f 036 A \0 \0 027 B
00000c0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
...(etc)...
I've looked into GBFINIT (in gbr2c.F). It appears that the first bytes
of the IVOLUME array are modified when GFVOLU (line 1208) is called in
late iterations of the first do loop of GBFINIT. This appears when the
ICHM > 35, e.g. when NAME1 = 'C3' (i.e. ICHM = 36). For 1 < ICHM < 36,
the first words in IVOLUME, i.e. the ones describing T1, are _not_
modified. This I believe is the right behaviour. So, something goes
wrong in the last iterations of the do loop.
Could this be a matter of the size of the GCBANK common block? Or has a
bug been introduced while embedding C3 into BRAG?
I've spent a couple of days partly on this problem already. Therefore,
before I spend more time, I'd just like to see if someone else out there
has any ideas.
Best wishes from
Jens Ivar
--
_____________________________________________________
________| Jens Ivar Jřrdre |_______
\ | Dept. of Physics Office: 521 | /
\ | Allégt 55 Phone: +47 55 58 27 92 | /
\ | 5007 Bergen Fax: +47 55 58 94 40 | /
/ | Norway E-mail: jensivar.jordre@fi.uib.no | \
/ |_____________________________________________________| \
/__________) (_________\
** Set debug level. **
idebug 0 0 0 0 5
** Prepare for geometry setup. **
geoini
** Enable/disable spectrometer and detector components. **
set_tree mids z
set_tree fms1 o
set_tree fms2 z
set_tree t1 afo
set_tree t2 afo
** Finish geometry setup. **
geodef
geofin
** Initialize BRAG. **
call gb2c
** Open output cdat file. **
call gbfile('foobar.cdat')
** End session and exit. **
call gbend
quit
This archive was generated by hypermail 2.1.5 : Tue Apr 29 2003 - 18:19:51 EDT