Re: problems in USRBIN and SOURCE

From: Alberto Fasso' (fasso@SLAC.Stanford.EDU)
Date: Sun Oct 29 2006 - 20:43:55 CET

  • Next message: Avishay Cohen: "Re: Problem"

    Dear Wang,

    I have tried your source with;


    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
          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
          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

    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???


    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.


    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:

          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 )

    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.


    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

  • Next message: Avishay Cohen: "Re: Problem"

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