Re: Difficult geometry problem -- tentative resolution

From: Vasilis Vlachoudis <>
Date: Wed, 16 Jun 2010 14:39:26 +0200

Hi Joseph,

sorry, by mistake I've send you the wrong input file. Please find
attached the modified one that now passes a couple of debugging tests,
however still contains problems that I didn't fix.

By running the FLUKA debugger on a plane on Y=0 X:[-199:199] Y:[0:0]
Z:[-99,899] by 501x1x1001 bins I get the following error(s)

   **** Lookdb: Geometry error found ****
   **** The point: 198.205589 0. -32.2007992 ****
   **** is contained in more than 1 region ****
   **** (regions: 1 BlckHole 4 VacReg1 ) ****
... repeated many times...
Due to a logical error in the definition of the VacReg1

Unfortunately the debugger is unable to catch the small errors due to
slightly overlapping surfaces mainly from the ARB definitions. However
these errors are important during tracking especially if there is an
undefined region.
In the attached file ni30_n.err you will see a non-exhaustive list of
such errors (for the Y=0.0 plane only). It shows a location exactly on
the surface of a body that if you move slightly inside/outside it finds
a logical error.
Attached you can find also a couple images with the problematic regions
(these plots are coming from the new geometry debugging/editing tool for
flair I am preparing).
The problematic bodies are highlighted with red-lines.

I've corrected in your input some of them using some
intersections/subtraction in the problematic region with the body in
question, but there are several still.

A couple of other remarks
1. If you want to perform body transformation, in flair there is a
dialog under the menu input that does that. Moreover, in the new version
of FLUKA there will be input cards to perform transformations
2. indeed flair is changing the formatting of the input when it writes
to dist. This is unavoidable, since the program has to reconstruct the
card lines as strings from the internal objects, therefore it knows
nothing about the formatting habits of the user.
3. To run an input you it has to be saved first. However flair save's it
only there is something changed in the input.
4. In Geometry Plot, click in "Options" the "boundaries" then it should


On 06/15/10 20:47, Joseph Comfort wrote:
> Hi Vasilis,
> We are all scientists trying to solve problems. Your message did not
> specifically identify the 'logical errors' and so was not entirely helpful.
> I can assure you that I spent a huge amount of effort (and frustration)
> trying to debug the geometry, and only submitted a message when I
> concluded that additional sets of eyes should be helpful.
> Now we have a problem. The .inp file from which you started was
> attached to one of my messages as a limited one for my geometry, but one
> that worked. I just tried it again, and it works. But the input file
> you attached bombs!
> So what are the differences? You changed my RPP blackhole to a SPH.
> OK, and not an issue. Otherwise the definitions of the bodies were left
> unchanged. OK. The differences are in the definitions of the regions.
> 1) You subtracted a list of bodies (Fiduc to VacDet2) from the body
> World. This is unnecessary because they are all contained within the
> body of ChamHol. The other region of space that is subtracted away to
> form the World region contains ChamHol. However, I checked and the
> redundant subtraction does no harm.
> 2) The real error is in your modification of the region HolColl. You
> added a +CuColl. The region is entirely defined by the HolCol body and
> can stand alone. Your change led to immediate execution failure, with
> geofar messages and the array dumps. Logically, I am not sure that it
> should fail, but it certainly does.
> I have only recently started to use flair and, for me, it has limited
> appeal. There are also a few things I don't like.
> 1) If a job is 'Run' with flair, the input file is modified. Sometimes,
> I am happy with how I have formatted the input file and do not want it
> changed. The changes make the file harder to read and are less
> user-friendly.
> 2) I found that flair continues to read input cards and work with them
> even after a STOP line. I can understand the reasons, but it is harder
> to get a simple plot of the geometry soon after GEOEND without worrying
> about the rest of the file.
> 3) I have had problems with plotting or not plotting a region that has
> the same material (e.g., air or vacuum) as the area surrounding it. The
> control on the PLOTGEOM card does not seem to work as it reads to me,
> and I have to change the ASSIGNMAT cards. Maybe nothing can be done, or
> maybe it is just me.
> If you are developing easier and better ways to provide input for Fluka,
> as Alberto indicates, I'll look forward to them.
> Thank you,
> Joe
> Vasilis Vlachoudis wrote:
>> Hi Joseph,
>> you have logical errors in your geometry.
>> Find attached the modified input file correcting these problems.
>> Please next time before submitting a geometry problem try to debug it
>> properly.
>> V.

Vasilis Vlachoudis
Tel: +41-22-7679851
Fax: +41-22-7669644

GlobalView.png XZ1.png XZ2.png XZ3.png XZ4.png XZ5.png
Received on Thu Jun 17 2010 - 12:00:54 CEST

This archive was generated by hypermail 2.2.0 : Thu Jun 17 2010 - 12:00:54 CEST