From: Alberto Fasso' (fasso@SLAC.Stanford.EDU)
Date: Sun Oct 29 2006 - 20:43:55 CET
Dear Wang,
I have tried your source with;
open(21,file='../mountaindyw.near',status='old')
and the open statement written this way DOES work.
However, many other things don't work.
I will try to list not only a number of errors, but also examples
of bad FLUKA programming style, hoping that they will be useful also to
other users. By "bad FLUKA programming style" I mean ways of programming
which are possibly accepted by the compiler, but that increase the risk
of getting wrong results, mainly because of numerical rounding problems.
real PI, TWO_PI, HPI,rcut
parameter(PI=3.1415926, TWO_PI=PI*2.0,HPI=PI/2.0)
integer N,ii
parameter(N=1e6)
Real emuon(N),theta(N),phi(N),a,b,c
real x0,y0,z0, emu0,theta0,phi0
real DUMMY,arandom(3)
real area_cross,sx,sy,sz,sx_p,sy_p,sinphi,cosphi
real lRock,wRock,hRock
real beamx,beamy,beamz
The whole FLUKA is written in double precision. If a user wants to
declare his own floating point variables, they also MUST be in double
precision. The only exception is when those variables must be passed to
some external program which requires single precision (e.g. HBOOK).
Declaring coordinates, energy, angles as REAL, calls for bad trouble.
Pi and 2*Pi are already parameterized in COMMON DBLPRC (look it up in
$FLUPRO/flukapro):
PARAMETER ( PIPIPI = 3.141592653589793238462643383279D+00 )
PARAMETER ( TWOPIP = 6.283185307179586476925286766559D+00 )
Note the number of significant figures used! Actually they are prepared
for a possible future use in quadruple precision, but at least 16
significant figures should be used. It is strongly suggested to use
such pre-parameterized values, because they minimize the risk of
rounding problems. DBLPRC contains a lot of parametrized mathematical and
physical quantities. Please use them any time it is possible.
integer N,ii
parameter(N=1e6)
Strange that the compiler did not complain. How can you declare N as integer
(not necessary, since all variables beginning by I,J,K,L,M,N are already
declared as integers in DBLPRC), and then immediately after assign to it a REAL
value 1.e6???
phi(ii)=phi(ii)*PI/180.0
Write all floating point numbers with a d: 180.d0. A number written with a d
has about 16 significant decimal figures (double precision), without the d
only 6 figures (single precision). But because in FLUKA all calculations
are done in double precision, the next ten digits are filled with rubbish.
This tends to increase substantially the accumulated noise.
wRock=800
hRock=1210
Here not only the d is missing, but also the decimal point, making the
assigned value not even single precision but integer. It is true that
the Fortran rule allows that, doing an automatic conversion: but I
recommend to avoid this kind of sloppy programming, unfortunately very
common. It does not require a major effort to write instead:
wRock=800.d0
hRock=1210.d0
beamz= sqrt(1-beamx**2-beamy**2)
Here again, 1 is written instead of 1.d0. But many simple numbers
like 1, 2 etc., are pre-parametrized in DBLPRC as
PARAMETER ( ONEONE = 1.D+00 )
PARAMETER ( TWOTWO = 2.D+00 )
PARAMETER ( THRTHR = 3.D+00 )
PARAMETER ( FOUFOU = 4.D+00 )
etc.
It is not compulsory to use this notation, but it makes sure that the
numbers are written correctly, and at the same time makes easier to
search with an editor. ONEONE is easier to find than just 1.
I stop the examples here, but all the rest of your source routine is
programmed in the same way. I may look unnecessarily picky, but the
numerical accuracy is one of the greatest assets of FLUKA. I would like
to add that if users write clear and clean code, it is much easier
for us to help when something goes wrong, like in this case.
Alberto
On Sat, 28 Oct 2006, Wang RuiGuang wrote:
> Dear Alberto,
>
> Still have same problem although I have done according to your both ways.
>
> On Fri, 27 Oct 2006 07:09:30 -0700 (PDT), Alberto Fasso' wrote
> > Be careful: an open statement in your source routine must not refer
> > to a file in the current directory, because Fluka is running in a temporary
> > subdirectory. So, if the file to be opened is called xxxxx, the open
> > statement should refer to it as "../xxxxx" or give the whole
> > actual path: "/home/whatever/thisproblem/xxxxx"
> >
> > Alberto
This archive was generated by hypermail 2.1.6 : Mon Oct 30 2006 - 00:54:09 CET