RE: Difficult geometry problem -- tentative resolution

Hi Joe,

I am forwarding also this mail to the fluka-discuss list.

> It appears to me that Fluka does not like regions defined with a World
> volume (first layer inside the blackhole) and infinite planes. I
> suggest this is a program bug, but maybe there is a caveat somewhere.
> I found I could get around the problem by defining finite regions inside
> World.

I don't know what you mean by "a World volume": there is no such expression in Fluka's geometry jargon. If you mean that you cannot define an external
blackhole using open bodies such as infinite cylinders and planes, you are right:
the manual indeed says:
"The external blackhole must be completely surrounded by the boundary of a closed
body, and therefore cannot be defined by means of half-spaces or infinite cylinders only".
But in the input you have attached, "World" is a region inside the external blackhole
region "BlckHole", and therefore there should not be any constraint in defining it
by means of planes. I hope somebody will find the time to analyze your input to find
the error.
I am sorry, but I must insist on deprecating the use of ARBs that you seem to like so
much. Maybe they are not the cause of your present problem, but they can become
the cause of other problems. You seem to ignore that you can define a region as a collection
of pieces, separate or partially overlapping, by means of the OR operator ( | operator
in free format). An ARB is easily replaced by a combination of RPPs cut by
planes.

>From your previous mail:

> With regards to the other issues of the Fluka geometry, first I want to
> submit a very strong vote against removing the extra bodies. Leave the
> warning comments, but also leave (or improve) the features. This is the
> first time I used them, I tried to avoid them, but decided they were
> necessary to the case. An RPP, for example, only has edges parallel to
> coordinate axes, while I am dealing with rotated structures. Adding a
> rotated RPP (e.g., RPR) would be helpful, but some of my cases need the
> flexibility of ARB. In my opinion, Fluka already has too few body
> shapes.

The next FLUKA version will allow you to rotate RPPs (and to expand/shrink them).
The lack of flexibility is only apparent:: it is clear that you are looking
 for regions that can be described by simple + and - operations. This is why you find
that Fluka has too few body shapes. But using OR you can easily build more complex
shapes using the existing bodies.
However, another feature of the next version is that the user can define any
shape which can be described by a second degree equation. These can be closed
bodies (e.g. ellipsoids) but mainly open bodies (paraboloids, hyperboloids,
...)
Of course these are not the shapes you have in mind, but as I said, those
shapes can be easily built by combining the available ones (perhaps rotated
and expanded/shrunk).

> I am looking forward to the time that an XML approach can be used for
> Fluka. GDML works pretty well for Geant4; I had some students once who
> designed something similar to and even better than GDML at the time, and
> it was fabulous. The internal philosophies of Geant and Fluka are very
> different, and that is entirely good for me. No debate here. But I
> fear that Fluka is falling more and more out of the trends of how
> programs interface with people.

We know by experience that people coming from experience with Geant or similar
programs often find the FLUKA geometry unfriendly. But I can assure you that the
opposite is also true: users who have started with Combinatorial Geometry find
the Geant geometry difficult to use (you are probably surprised!)
Our preference for Combinatorial Geometry has deep reasons that it would be
long to argue about here in detail: in short, CG is far more accurate and is based on a concept
of sharp boundaries between regions (rather than "volumes" floating in a poorly defined
"mother volume") that allows importance biasing, fluence scoring at boundaries, precision
dosimetry at material interfaces and especially optimized transport of charged particles.
It looks to us that these advantages are much more important than friendly
user interfaces.
However, Vasilis Vlachoudis has developed a new technique (to be included soon in Flair)
that should make much easier the construction of a user geometry.

Kind regards,

Alberto

________________________________________
From: Joseph Comfort [Joseph.Comfort_at_asu.edu]
Sent: Sunday, June 13, 2010 5:25 PM
To: Fasso, Alberto
Subject: Re: Difficult geometry problem -- tentative resolution

It appears to me that Fluka does not like regions defined with a World
volume (first layer inside the blackhole) and infinite planes. I
suggest this is a program bug, but maybe there is a caveat somewhere.

I found I could get around the problem by defining finite regions inside
World. Attached is a start on reconstructing my geometry, for part of
the first portion of the beamline. (More stuff is needed.) A picture
from flair is also attached. All output files are quite normal.

There are NO reported geometry or runtime errors so far with limited
testing. Note that the input file includes several ARBs, and some ARBs
inside ARBs. High-precision input has not been used. Maybe some errors
will show up later. I will eventually run millions of events. I am
including several pseudo-detectors along the beamline (the horizontal
axis at 0) to check profiles for peculiar behaviors.

I think people were misled by the unusual use of some bodies. There is
no proof yet that they were the source of the problems. Rather, it was
the (too-)simple (?) use of an infinite plane that led to failures. At
least, so far, so good.

Joe Comfort