RE: Tracklength scoring with USRBIN

From: Vasilis Vlachoudis <Vasilis.Vlachoudis_at_cern.ch>
Date: Fri, 3 Oct 2008 09:49:47 +0200

Hi Chris,

particle tracks are forced to stop at the boundaries of regions.
Therefore by adding the scoring region, your scoring and the USRTRACK
have to be identical. If there is no region, you will never get the
track to be stopped on your virtual "USRBIN" scoring boundary. However
the (TRACKR) common contains all the information you need. Using this
common you can find the track-subinterval that falls between your
virtual boundary and interpolate the quantity you want to score. You
don't need any complicated code to find the interval since all USRBIN
options are aligned with the axes, therefore the solution is straight
forward.

Best Regards
Vasilis

-----Original Message-----
From: owner-fluka-discuss_at_mi.infn.it on behalf of Chris Theis
Sent: Wed 1/10/2008 10:58
To: fluka-discuss_at_fluka.org
Subject: Tracklength scoring with USRBIN=20
=20
Dear all,

I'm currently facing some problems where I would need some more detailed
information about the scoring mechanisms of the code. Any hints to solve
the following issue would be greatly appreciated.

Recently I've developed a number of routines that extended the USRBIN
card in order to score fluence spectra with a specified energy
resolution instead of the integral value. The aim was to obtain a
scoring method which is independent of geometry regions in contrast to
the USRTRACK card.

For this purpose I defined a number of 1-bin USRBIN detectors at a
certain location and then used FLUSCW to interface some of my own
book-keeping classes. A number of cross-checks of the obtained fluence
spectra with those from the USRTRACK card showed nice agreement.
However, when I removed the geometry region which was required for the
USRTRACK card and re-ran the simulation the fluence spectra obtained by
my USRBIN extensions suddenly changed. I basically obtained the same
spectral shape but the absolute values were shifted.

After an extensive number of tests I came to the conclusion that this
behavior should be caused by a shift in the tracklength values that are
passed to FLUSCW. From my understanding FLUSCW is called by the
applicable USRBIN detector (USERWEIGH WHAT(3) =3D3D 3.0) but the
tracklength
passed is the total tracklength and not the part which traverses the
actual volume of the USRBIN detector. Due to the presence of a vacuum
region, which I used for scoring in my tests, these two values
accidentally coincided as the USRBIN and the geometry region had
identical extensions and placement.=3D20

This leads me to the question whether there is the possibility to obtain
the actual tracklength within the respective USRBIN as FLUKA needs to
have this information available for its own scoring, and how to do it?
Of course I could extract part of SimpleGeo's own tracker and interface
it to obtain the appropriate portion of the total tracklength. However,
I'd like to avoid this situation if possible. On one hand it would
introduce unnecessary complexity and on the other hand it would entail a
runtime penalty as basically the same calculations, which have been done
by FLUKA already, have to be repeated by myself a second time.

Any help on this matter would be greatly appreciated!

Best regards
Chris

------------------------------------------------------------------------
Chris Theis
CERN/SC-RP - European Organization for Nuclear Research
1211 Geneva 23, Switzerland
e-mail: Christian.Theis@cern.ch www: http://www.cern.ch/theis
------------------------------------------------------------------------
Received on Fri Oct 03 2008 - 10:09:48 CEST

This archive was generated by hypermail 2.2.0 : Fri Oct 03 2008 - 10:10:18 CEST