Re: FLUKA: About GEOTRK
Hi Alberto,
Thanks for your prompt reply.
I realize you cannot debug other packages, but anyway here is the GEOTRK
routine I'm using. It would be great if you can have a look at it.
With the following (and only) USRBIN:
> USRBIN 11.0 8.0 71.0 111.47 0.0 187.0
> MODE
> USRBIN 11.47 0.0 -63.0 1.0 2.0 &
I've put by hand (to debug) the computation that I used to do elsewhere
(in ALTrackLengthBinning), and indeed find the same (wrong) result :
for the 2nd bin RULLTOT = 6.291058e-05 whereas in unit 71 it is
3.7571E-05.
Hope that with the routine itself you'll be able to spot the error (must
be obvious, but I do not see it).
...
LOGICAL RULLTOTFIRST
SAVE RULLTOTFIRST
DATA RULLTOTFIRST /.TRUE./
...
ENTRY GEOTRK ( IJ, XA, YA, ZA, MREG, RULL, ICALL, LLO,
& ECONTR )
IEST = 1
NEWREG = MREG
IF ( ECONTR .LT. ZERZER ) THEN
WRITE(LUNERR,1000) ECONTR,ICALL,IJ,MREG,NEWREG,IEST
RETURN
END IF
* User defined track-length binnings
IF ( LUSTKB ) THEN
CALL USRSTB ( IJ, XA, YA, ZA, MREG, RULL, ICALL,
& LLO, ECONTR )
IF ( IJ .EQ. 8) THEN
R = SQRT(XA*XA+YA*YA)
IF ( R .GE. 1.147D+01 .AND. R .LE. 1.1147D+02 .AND.
& ZA .GE. 6.2D+01 .AND. ZA .LE. 1.87D+02) THEN
volume = PIPIPI*(1.1147D+02*1.1147D+02- 1.147D+01*
& 1.147D+01)*(1.87D+02-6.2D+01)
IF ( RULLTOTFIRST ) THEN
RULLTOT = 0.D+0
RULLTOTFIRST = .FALSE.
ENDIF
RULLTOT = RULLTOT + RULL/volume
WRITE(*,2001) IJ, R, ZA, MREG, RULL, ICALL,
& LLO, ECONTR, KTRACK, RULLTOT
ENDIF
CALL ALTrackLengthBinning(ij,xa,ya,za,mreg,rull,ktrack)
2001 FORMAT(1X,I5,2(1X,G15.3),I5,G15.3,2I5,G15.3,I5,G15.3)
ENDIF
ENDIF
Alberto Fasso' wrote:
> In principle no. Or better yes, it does things like multiplying by
> FLUSCW, and finding the address of the bin which has been dynamically
> allocated: but this should not affect the result in your case.
> The problem is, it is nice for a user to do his own scoring (or biasing,
> or whatever), but it makes very difficult for us to debug it. There
> are many points where one can introduce an error, and they are all outside
> our control. This is exactly the reason why we encourage everybody to
> use as much as possible the standard scoring facilities, which have been
> ultra-debugged by years of our own mistakes :-)
>
> All help I can give you is to suggest some obvious checks:
> 1) Is the ratio between the standard results and yours constant for all
> bins? If yes, the ratio could point to a normalization error (wrong
> volume, wrong total weight of primaries). Fortunately you have only one
> bin in R, so all the bins have the same volume.
> 2) Check the same after having shifted by 1 bin your results in both
> directions (possibility that you have miscalculated the bin number).
> 3) Some histogramming packages (I don't know about ROOT) don't work
> in the same way as the binnings of FLUKA in the case where the content
> of some bins is zero: they try to "fill" the empty intervals by
> making bins of non-uniform width.
> 4) Are you scoring only total fluence or are you histogramming also versus
> energy or other variables? In this case, how do you compare with
> standard scoring? Be careful about the neutron group energy structure,
> ROOT will probably make energy histograms of uniform width, which are
> incorrect in this case: and when summing, you may get a wrong result.
> 5) FLUKA variables are all in double precision. With programs such as
> HBOOK and PAW it is necessary to convert the scored values to single
> precision before scoring. How about ROOT?
>
> This is everything I can think about for the time being.
>
> Alberto
>
> --
> Alberto Fassò
> CERN-EP/AIP, CH-1211 Geneve 23 (Switzerland)
> Phone: (41 22) 767 2398 Fax: (41 22) 767 9480 Alberto.Fasso@cern.ch
--
Dr. Laurent APHECETCHE (mailto:aphecetc@in2p3.fr) (IN2P3-CNRS)
SUBATECH-EMN-4 rue Alfred Kastler-BP 20722-44307 NANTES cedex 03
TEL (+33/0) 2 51 85 84 17 - FAX (+33/0) 2 51 85 84 24 (France)
Collaborations PHENIX http://www.phenix.bnl.gov/~aphecetc et MEGAPIE.
Partial thread listing: