RE: Difficult geometry problem

Hi Joe,

I have some comments to make to what you and Sebastien have written.

> I thought I had used ARBs before, but do find such files at the moment.
> Even so, I do not think they are the issue. The manual recommends
> against them, mainly because they can be replaced by infinite planes.

ARBs, WEDs and BOXes should NEVER be used. They can indeed be replaced by
infinite planes, but that is not the reason: it is just a guide about how
to replace them.
The reason is exactly what has happened to you: they are very likely to
generate errors due to the difficulty for the user to define vectors
EXACTLY perpendicular with high precision (another reason is that they are
not optimized for tracking speed,
but this is not relevant in this discussion). They have been inherited
from a primitive version of
Combinatorial Geometry in codes that were transporting only neutrons and
photons, and therefore did not have the requirement of high accuracy tracking
due to multiple scattering and magnetic fields. But even in those old codes,
it was not unusual that a particle would be "lost" and could not be tracked.
The solution at that time was simply to ignore that particle and continue
with another.
In designing the FLUKA geometry, a special effort has been made to avoid
any such sloppy "fix": ALL particles must be tracked correctly.
This has been the main reason to introduce the new bodies, especially the
planes.
We have considered several times whether we should eliminate completely
the three "dirty bodies", but we have kept them for historical reasons.

> But having 6 planes with perpendicular vectors for each ARB will be a
> challenge to generate and a nightmare for anyone to comprehend the input
> file and deal with the logic. I do not see them as being an issue where
> they have been used (unless there is an error in my coding or in the
> code itself).

Using 6 planes is not a nightmare. There are two ways:
- to enclose the part of space where you would like to have a BOX or ARB
  inside an RPP which can be subtracted from the rest of the geometry, and
  to define the plane intersections (+, -, and OR) only inside that RPP.
- to use parentheses

> A more likely issue for precision, it seems to me, is where the beam
> pipes are making holes in the flanges. That is why I made the pipes a
> little longer than needed and then cut them with infinite planes. I
> examined these regions carefully, and have not yet found errors from the
> GEOEND checks.

That is the correct way: to make long cylinders (better, infinite cylinders!)
and to cut them with planes. I take the opportunity to stress that
infinite cylinders (XCC, YCC, ZCC) are much better than closed cylinders
(RCC). RCCs should be used only when not parallel to one of the axes.

> In my way of thinking, it seems most peculiar to require high-accuracy
> precision on geometrical input data when it can't even be known
> physically to that degree, and in many cases is not relevant even with
> less accuracy. It's a program design issue. I tried to design around
> it, but apparently not well enough.

This is a very common misunderstanding that would be worth a long
discussion. In Monte Carlo, precision must not only reflect user knowledge,
but maximum precision is necessary for the sake of CONSISTENCY.
For instance, the three direction cosines of a particle trajectory MUST be
normalized so that the sum of the squares is exactly 1 with maximum
precision,
even if the user has only a vague idea about the particle direction! If
this is not ensured, a computer crash is likely to happen due for instance to the
square root of a negative number.
In the computer world, nothing is as wrong as the rule that we learnt in
school to write numbers only with the number of significant digits defined
by then measurement error.
In FLUKA, numbers are always written
WITH THE MAXIMUM POSSIBLE NUMBER OF SIGNIFICANT DIGITS (in double precision).
(Have a look at the include file (DBLPRC) in the $FLUPRO/flukapro
directory). Ignoring this need of systematic maximum precision is the most
common mistake made by users when writing user routines.

By the way, Sebastien's suggestion to use high precision format in body
definitions is correct, but it is equally correct (and simpler) to use
free format.

> One wish: It would be really, really helpful if there was some
> intermediate structure in the geometry, i.e., a complex region that
> could be built and then added as a unit into the geometry stream with a
> position and rotation (with all precision issues taken care of).

Something of this kind will be available in the next FLUKA version, to be
released soon:
- an #include directive switching the input stream from the original input
file to a different file, and back to the original file after the end-of-file
is met.
  It can be applied also to geometry input.
- Geometry directives allowing to perform coordinate expansions,
  coordinate translations or coordinate roto-translations of defined bodies
In addition, other possibilities (roto-translations of regions) are already
available now via the LATTIC option. Normally this option is considered only for its
capability to build geometry with symmetrical repetitions: but it can also be
used to describe a "prototype" region located sometimes in a non-accessible
location (e.g. inside the blackhole), and to make a copy of it translated
and rotated somewhere else.

Kind regards,

Alberto
Received on Sat Jun 12 2010 - 16:43:04 CEST