Re: FLUKA: About GEOTRK
Dear Laurent
just a naive question: are the binning boundaries laying exactly on region
boundaries? If not you can incorrectly score steps whose end point is
INSIDE the given Rmin-Rmax, Zmin-Zmax bin, but that is partially outside
the bin. USRSTB is doing muuuch more than simply scoring according to
the ned point (xa,ya,za), actually it ignores xa,ya,za and instead it
makes use of (xtrack(j),ytrack(j),ztrack(j),j=1,ntrack), which are the
vectors containing the whole story of that step.
x,y,ztrack(0) is the starting position, x,y,ztrack(ntrack) the final one,
for neutrons ntrack is 1 always. USRSTB splits accurately the real track
segment across the various R-Z bins, computing exactly the fraction of the
length belonging to each individual bin. If each bin corresponds to a
region using xa,ya,za could give similar results (with the caveat that the
end step position being exactly ON a boundary can cheat all naive checks
of .GE./.LE.because it should correspond EXACTLY to one of the R or Z
boundaries), if several bins are (partially) contained into one region,
steps will in general span more than one bin at time and you method will
never work!
I can only stress once more Alberto's point, the builtin scoring functions
are sophisticate stuff which underwnet a lot of debugging and testing. use
it as much as possible!
USRSCO, the routine USRSTB is an entry point of, manages both fluence
binning and energy deposition binning correctly splitting into the right
subtracks whichever step spanning a R-Phi-Z or a X-Y-Z binning. The
resulting stuff is quite a complex piece of code (4732 lines...) whose
performances cannot be easily emulated with a few lines. Of course if you
were scoring collision densities, where the "event" is really point-like,
your aprroach would have been perfectly sensible.
Hoping this helps!
Ciao
Alfredo
On Wed, 7 Nov 2001, Laurent Aphecetche wrote:
> 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
>
>
--
+----------------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.767.6119 |
| CERN-SL || Fax.: +41.22.767.7555 |
| 1211 Geneva 23 || e-mail: Alfredo.Ferrari@cern.ch |
| Switzerland || Alfredo.Ferrari@mi.infn.it |
+----------------------------------------------------------------------------+
Partial thread listing: