**From:** Alberto Fasso' (*fasso@SLAC.Stanford.EDU*)

**Date:** Sun Oct 29 2006 - 20:43:55 CET

**Previous message:**RZ: "Log message explanation needed"**Maybe in reply to:**Wang RuiGuang: "problems in USRBIN and SOURCE"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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
*

**Previous message:**RZ: "Log message explanation needed"**Maybe in reply to:**Wang RuiGuang: "problems in USRBIN and SOURCE"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]

*
This archive was generated by hypermail 2.1.6
: Mon Oct 30 2006 - 00:54:09 CET
*