Dear Franz
I am not surprise by your result which highlight the importance of having proper checks of the geometry with the various debugging options (flair, FLUKA, SimpleGeo....) before running the production calculations.
The strategy in FLUKA is to minimize the time spend on particle tracking through the geometry. Basically when you transport the particle, the code check (based on the track length), if the boundary of the region is crossed at the next calculated interactions points. If this is the case, the new region has to be found to start tracking from the boundary (sampling of new interaction points).
The first time, the code will loop sequentially over the region until it finds a region where the particle enter (and will stop without checking for other possible candidates which would be too penalizing CPU wise).
The new region is then associated as a likely neighbour for the regions which has been left left (in the array with the dimension specified for initialization after the region name in the input ). The next time the new region will be searched based on the likely neighbour (stored in the array) which speeds up the time spent on tracking for complex geometry. So if you have a geometry which is not properly defined as you have illustrated you may always track in one of the two possible regions but as it is a random process it could be that depending from where you enter the region FLUKA consider water or air leading to even more strange results. The order in the region definition may also change the result, thus the importance of my first statement...
The debugger will however test all candidate regions and report overlaps (or missing regions which would also be reported during transport in that case)
Greetings
Joachim
-----Original Message-----
From: owner-fluka-discuss_at_mi.infn.it [mailto:owner-fluka-discuss_at_mi.infn.it] On Behalf Of Franz Siegfried Englbrecht
Sent: 13 March 2015 18:11
To: fluka-discuss_at_fluka.org
Subject: [fluka-discuss]: Can FLUKA start with errors in the geometry definition?
Dear colleagues,
I am experiencing an unexpected behaviour with the combinatorial geometry. FLUKA does not refuse to run when a wrong definition of one body containing another one is defined in the input as follows:
My testcase consists of two cubes. Cube1 made of water and the smaller
cube2 made of air in the middle of cube1 (geo.png):
*The correct definition of this geometry would be (see attached beam.inp)
BLKBODY 5 +blkbody -void
VOID 5 +void -cube1
OUTER 5 +cube1 -cube2
INNER 5 +cube2
A 110 MeV proton beam (range ~9cm in water) is simulated.
A USRBIN is used to score the energydeposition in 1D in beamdirection (1.png).
*If I do not subtract the inner cube (cube2) from the outer one (cube1), the inputfile looks like
BLKBODY 5 +blkbody -void
VOID 5 +void -cube1
OUTER 5 +cube1
INNER 5 +cube2
The geometry editor reports 'Errors found' for this case, but the simulation of this geometry starts, runs without reporting an error and produces a USRBIN.
The 1D energydeposition looks like FLUKA treated the inner cube as it was water / non-existent (2.png).
Please find attached the inputfile with the correct definition, as well as the two plots of depth vs energydensity.
Best,
Franz
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id¬c_info
Received on Mon Mar 16 2015 - 17:15:12 CET