RE: Tracklength scoring with USRBIN

Hi Vasilis,

as I need to support more complex scoring volumes, like non-axis aligned
tubes with arbitrary orientation in space, I'm afraid the solution will
not be as straight-forward. But with the values from (TRACKR) I can do
the calculation with my own routines.

Thanks a lot for the info & have a nice day
Chris

------------------------------------------------------------------------
Chris Theis
CERN/SC-RP - European Organization for Nuclear Research
1211 Geneva 23, Switzerland
Phone: +41 22 767 8069 Office: 892-2A-015
e-mail: Christian.Theis@cern.ch www: http://www.cern.ch/theis
------------------------------------------------------------------------

> -----Original Message-----
> From: Vasilis Vlachoudis
> Sent: 03 October 2008 09:50
> To: Chris Theis; fluka-discuss_at_fluka.org
> Subject: RE: Tracklength scoring with USRBIN
>=20
> Hi Chris,
>=20
> 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.
>=20
> Best Regards
> Vasilis
>=20
>=20
> -----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
> Dear all,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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
>=20
> 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.
>=20
> Any help on this matter would be greatly appreciated!
>=20
> Best regards
> Chris
>=20
>=20
>=20
>
-----------------------------------------------------------------------
> -
> Chris Theis
> CERN/SC-RP - European Organization for Nuclear Research
> 1211 Geneva 23, Switzerland
> e-mail: Christian.Theis_at_cern.ch www:
http://www.cern.ch/theis
>
-----------------------------------------------------------------------
> -
>=20
>=20
Received on Fri Oct 03 2008 - 10:09:46 CEST