Last version:
FLUKA 2023.3.3, January 31st 2024
(last respin 2023.3.3)
flair-2.3-0d 13-Sep-2023

News:

-- Fluka Release
( 31.01.2024 )

FLUKA 2023.3.3 has been released.
Next FLUKA Course
The 23rd FLUKA course
will be held at the Lanzhou University, China, on June 1-8, 2024

# Geometry

Q:

What is the maximum number of regions allowed in FLUKA?

A:

The maximum number of regions is 1000, but can be increased to 20000 by means of option GLOBAL (WHAT(1)). Using the LATTICE option in the geometry, however, it is possible to define regions as copies obtained by geometric transformations (rotations and translations). The number of such copies is unlimited, within the available computer memory.

Q:

Is there a maximum of the number of characters in each line of a geometry input?

A:

Yes, in a geometry input each line must not exceed a certain number of characters, as shown below. Any further characters are skipped when FLUKA reads the input.
```Old, number-based input:
"normal" format            : 70 characters (2X,A3,I5,6D10.3)
"extended precision" format: 76 characters (2X,A3,I5,3D22.15)
"normal" format            : 73 characters ( 2X, A3, I5, 9(A2,I5) )
"extended reg. num." format: 73 characters ( 2X, A3, I5, 7(A2,I7) )
New, name based input: max 132 characters```

Q:

Is there a function in FLUKA that returns for a certain point in space (x,y,z) the region number to which the point belongs as well as the lattice number, if it is a lattice replica?

A:

In principle one can call the following subroutine:
`    CALL GEOREG ( X, Y, Z, NREG, IDISC )`
where X, Y, Z are the coordinates of the point where you want to know the region (returned in NREG) and the lattice (returned in MLATTC in common LTCLCM). IDISC is a flag which, if different from zero, signals you are already out or going out of the geometry.

However, the situation is slightly more complex:
• GEOREG is very CPU ineffective like all "point" like geometry calls: it is ok to use it provided this is not done too often (geometry tracking based on a sequence of GEOREG calls instead of real tracking calls could be thousands of times slower in complex geometries). GEOREG loops on all regions/lattices until it finds where the point lies. On the contrary real step like calls can exploit many effective optimizations which makes them able to check at maximum 2/3 regions even in complex geometries
• GEOREG should be called with care when X,Y,Z lies on the boundary between two regions. This is a very common situation at run time, since all steps meeting a boundary end up exactly in that situation. The region returned by GEOREG in that case can be (pseudo-randomly) any of the two regions separated by that boundary, and there is no guarantee that the one returned is coherent with the one returned by the last tracking step. More specifically, the last step direction cosines are used to decide which region/lattice is returned (the one returned is the one the direction is pointing "into" if X,Y,Z lies on a boundary, even though the "current" direction referred to a step in a completely different position). In case one wants to input his own choice of cosines for this purpose (and for this purpose only), the call to GEOREG must be preceded by a call to:
`     CALL GEOCRS ( TXX, TYY, TZZ )`
where TXX, TYY, TZZ are the direction cosines (properly normalized to 1 in double precision)
• It is safer to save MLATTC/NEWLAT (common LTCLCM) before the call to GEOREG and restore them after, if GEOREG is called from unexpected situations (i.e., in the middle of an event). Furthermore in those cases the tracking optimization will be destroyed for the next step resulting in some CPU penalty

Last updated: 26th of April, 2016