RE: RE: Can FLUKA (or flair ) be used to caculate region volumes?

From: Alberto Fasso' <fasso_at_mail.cern.ch>
Date: Mon, 16 Apr 2012 16:29:47 +0200

Dear Walker,

if you use the method described by Anna, you will not have any problem.
You just have to use BEAMPOS with SDUM=FLOOD, and calculate track-length for
all regions you wish with a single "Region binning".
Track-length scoring in a region does not depend on how the region is
defined.

If you don't want to assign VACUUM to all regions, just use a neutrino as
a source particle (but remember to "undiscard" it).

By the way, for the time being you still need to multiply your results
by R/3 (where R is the radius of the sphere defined with BEAMPOS)
but the option to calculate volumes (and boundary areas) will be soon
implemented in FLUKA itself, with an error requested by the user.

Alberto

On Mon, 16 Apr 2012, walker wrote:

> Thanks, Chris!
> I found the 'Quasi-Monte Carlo' option and it even got a more accurate
> result than the 'Geometric' option sometimes. However, it still fails to
> get the right volume of a
> rendering-artefacts model I've got. Part of the FLUKA input of the model is
> as following:
>
> **************************************************************
> GEOBEGIN
> *Titile card
> 0 0 A small test
>
> *description of fluka bodies
> ZCC B1 0.0000000 0.0000000 10.0000000
> YZP B2 10.0000000
> XYP B3 0.0000000
> XZP B4 10.0000000
> XYP B5 10.0000000
> XZP B6 0.0000000
> YZP B7 0.0000000
>
> END
> *description of fluka regions
> R1 5 -B1 +B2 -B3 +B4 +B5 -B6 -B7
>
> END
> GEOEND
> **************************************************************
> The Region R1 is the boolean result of a a RPP ( which is formed by six
> planes instead) subtracting ZCC.
>
> Case1: When R1 is descriped by a RPP subtracting a ZCC, the rendering and
> volume caculation is OK, as following cut:
> [IMAGE]
>
> Case2: When R1 is described by boolean operations of the 6 planes(of the
> RPP) and the ZCC like the input showed above,there are rendering and
> caculation problems :
> [IMAGE]
>
>
>
> So in this simple example, the problem can be avoided by using RPP instead
> of containing planes. Yet, there are other situations in which lots of
> planes or other bodies
> (which can't be replaced with RPPs or so) exist with the rendering and
> caculation problem showed above.
>
> Then, is there any way to avoid the problem?
>
>
> Best regards
>
> Walker
>
>
>
> ____________________________________________________________________________
>
>
> From: Chris Theis
> Date: 2012-04-13 15:31
> To: wdx456
> CC: Sion Koren; fluka-discuss
> Subject: RE: Re: Can FLUKA (or flair ) be used to caculate region volumes?
> Dear Walker,
> SimpleGeo offers two kinds of volume calcultions. The one is called
> "geometric" and uses the visualized and as such
> discretized geometry. As a consequence it is very fast but might fail in ca
> se of
> rendering artefacts. There is another one which is called "Quasi
> Monte Carlo" which calculates the volume integral by using stratified
> numerical sequences which act on the analytic description of the geometry.
> Therefore, this method also works in the presence of rendering artefacts.
> If you are looking for the functionality to calculate volumes of arbitrary
> regions directly in your input, like it is provided for example in MCNP(X),
> then I'm afraid that FLUKA itself does not provide such a feature
> - at least not to my present knowledge. Eventually you can do it but you
> will need to do a bit of programming or set up a specific geometry, input
> and post-processing to achieve this.
> Hope that helps
> Chris
> ---------------------------------------------------------------------------
> -------------
> Chris Theis
> CERN/DGS-RP - European Organization for Nuclear Research
> 1211 Geneva 23, Switzerland
> Phone: +41 22 767 8069 Office: 892-2A-015
> e-mail: Christian.Theis_at_cern.ch<mailto:Christian.Theis_at_cern.ch> www: http:
> //www.cern.ch/theis
> ---------------------------------------------------------------------------
> --------------
>
>
>
Received on Tue Apr 17 2012 - 13:56:15 CEST

This archive was generated by hypermail 2.2.0 : Tue Apr 17 2012 - 13:56:46 CEST