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

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:
   Body reading:
        "normal" format            : 70 characters (2X,A3,I5,6D10.3)
        "extended precision" format: 76 characters (2X,A3,I5,3D22.15)
   Region reading:
        "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

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:

a) 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

b) 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)

c) 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