From: Fabio Bellini (Fabio.Bellini@roma1.infn.it)
Date: Thu Nov 23 2006 - 14:28:22 CET
Hi Alberto
thanks a lot for the prompt help.
I'm running more simulations to double-check results
but it seems you won the bet.
cheers
fabio
On Wed, 22 Nov 2006, Alberto Fasso' wrote:
> It is always difficult to help when user routines are involved, especially
> complex ones like this. However, I have noticed a couple of things which
> COULD (note: not necessarily will) generate trouble. Correcting them COULD
> eliminate the the error: in any case it is worth to try.
>
> - Several user variables are declared REAL*4, rather than the default DOUBLE
> PRECISION. Is that really necessary? Some of them (X1, X2) are used in
> expressions where they appear squared: FR(2) = PGR*(X2*X2-X1*X1)*(Z3-Z2)
> It is easy to lose precision in such cases.
> In other cases, variables are in double precision, but are not initialized
> with the D (e.g. array COSZEN). Several constants (1., 540.) are also written
> without the D.
>
> - The lack of double precision is especially dangerous in subroutine
> UNIDIR:
> PHI = 2.0*PIPIPI*FLRNDM( DUMMY )
> Z = 2.0*FLRNDM( DUMMY ) - 1.0
> T = SQRT( 1.0-Z*Z )
> X= T*COS(PHI)
> Y = T*SIN(PHI)
> Since X, Y and Z here above appear from the context to be direction cosines,
> there is a large chance that they lead to bad normalization, a likely
> candidate for the crash. I suggest to set instead:
> PHI = 2.D0*PIPIPI*FLRNDM( DUMMY )
> Z = 2.D0*FLRNDM( DUMMY ) - 1.D0
> T = SQRT( 1.D0-Z*Z )
> X= T*COS(PHI)
> Y = T*SIN(PHI)
> or better:
> PHI = TWOTWO*PIPIPI*FLRNDM( DUMMY )
> Z = TWOTWO*FLRNDM( DUMMY ) - ONEONE
> T = SQRT( ONEONE-Z*Z )
> X= T*COS(PHI)
> Y = T*SIN(PHI)
>
> I suggest to correct at least the above in UNIDIR, and see if the problem
> disappears. There are also other minor points, for instance PGR, initialized
> as 3.14159, while PIPIPI is correctly used elsewhere. But I bet that the crash
> is due to bad cosine normalization
>
> Alberto
>
>
> On Tue, 21 Nov 2006, Fabio Bellini wrote:
>
>> Hi
>>
>> I get a reproducible crash while running my fluka executable.
>> I have my own source routine but the crash doesn't seem (to me) to depend
>> on it.
>> The version of fluka is fluka2006.3
>>
>> you can find below the gdb debbuger report. Source code, input file and
>> auxiliary files, .out and .err are in the bug_report.tar.gz file
>> attached.
>>
>> to compile:
>> lfluka -m fluka -F flukahp -L $CERNLIB -l mathlib -l packlib -L $FLUPRO/ -o Q_exe *.f
>>
>> external source:
>> setenv FLUDAT $path/ext
>>
>> to run:
>> rfluka -M1 -N0 -e Q_exe cuore_ACBORPWD_D001
>>
>>
>> the program crashes at event 753523.
>>
>> any help is welcome.
>> thanks in advance
>>
>> fabio
>>
>> *********************** gdb debbuger
>> report***********************************
>> gdb ../Q_exe core.1074
>> GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
>> Copyright 2003 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you
>> are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for
>> details.
>> This GDB was configured as "i386-redhat-linux-gnu"...
>> Core was generated by
>> `/home/cuore/bellini/workdir/cuore_fluka_2006/Q_exe'.
>> Program terminated with signal 6, Aborted.
>> Reading symbols from /usr/lib/libg2c.so.0...done.
>> Loaded symbols for /usr/lib/libg2c.so.0
>> Reading symbols from /lib/tls/libm.so.6...done.
>> Loaded symbols for /lib/tls/libm.so.6
>> Reading symbols from /lib/libgcc_s.so.1...done.
>> Loaded symbols for /lib/libgcc_s.so.1
>> Reading symbols from /lib/tls/libc.so.6...done.
>> Loaded symbols for /lib/tls/libc.so.6
>> Reading symbols from /lib/ld-linux.so.2...done.
>> Loaded symbols for /lib/ld-linux.so.2
>> #0 0xffffe002 in ?? ()
>>
>>
>> (gdb) bt
>> #0 0xffffe002 in ?? ()
>> #1 0x42028c55 in abort () from /lib/tls/libc.so.6
>> #2 0x40030cc1 in sig_die () from /usr/lib/libg2c.so.0
>> #3 0x40030507 in s_rnge () from /usr/lib/libg2c.so.0
>> #4 0x0804a170 in source_ (nomore=0x0) at source-Q.f:647
>> #5 0x080db8c0 in feeder_ (kendcn=0x90d5364) at feeder.f:176
>> #6 0x0804f47a in flukam_ (iflgeo=0x84a0528) at flukam.f:3101
>> #7 0x08049312 in MAIN__ () at fluka.f:278
>> #8 0x084a0436 in main ()
>> #9 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6
>>
>>
>> (gdb) frame 4
>> #4 0x0804a170 in source_ (nomore=0x0) at source-Q.f:647
>> 647 RETURN
>> Current language: auto; currently fortran
>>
>>
>>
>>
>> (gdb) list
>> 642 * Do not change these cards:
>> 643 CALL GEOHSM ( NHSPNT (NPFLKA), 1, -11, MLATTC )
>> 644 NLATTC (NPFLKA) = MLATTC
>> 645 CMPATH (NPFLKA) = ZERZER
>> 646 CALL SOEVSV
>> 647 RETURN
>> 648 *=== End of subroutine Source
>> =========================================*
>> 649 END
>> 650
>> 651 SUBROUTINE UNIDIR( X,Y,Z )
>
> --
> Alberto Fassò
> SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
> Phone: (1 650) 926 4762 Fax: (1 650) 926 3569
> fasso@slac.stanford.edu
>
>
This archive was generated by hypermail 2.1.6 : Thu Nov 23 2006 - 14:47:32 CET