Implementation of a Steel Grid Structure in FLUKA

Hello everyone,

I need to implement a steel grid structure laid on the floor. Here are the main characteristics of the geometry:

  • The master cell spans the coordinates: (-100,-97), (-410, 290), and (-300, 288)
  • Each sub-grid (or unit cell) has the following dimensions (in cm): x= 3 , y = 3.4 , and z = 6.9
  • Each small grid element includes a thin steel boundary

Now, I’m defining all the FLUKA REGION and RPP cards, essentially building ~17,000 regions (about 200 x 85) with the help of the LATTICE cards. I wrote a python script to generate the FLUKA input cards automatically. This approach is extremely inefficient, and FLAIR becomes very slow to handle such a large input. Moreover, when I try to visualize the geometry in FLAIR, I get the following warning: “Nesting level exceeded maximum. Possible LATTICE infinite loop.”

Is there a smarter or more efficient way to implement this kind of large, regular steel grid in FLUKA, ideally avoiding this error?

One idea I had was to use the lattic.f user routine to define the repeated structure at runtime, but I don’t know if this solution would be more efficient. Anyway, I’m not entirely sure how to implement it correctly for this use case. Any guidance or examples on how to proceed would be greatly appreciated.

Thanks in advance for your help!
Giorgia

Dear @giorgia.fossati,

Could you please add here the current input file that you have, and of just the unit cell?

One idea that comes to mind is to to replace the RPPs with infinite planes, thereby improving also the tracking algorithm.

Your warning could also mean that there are errors within the geometry, e.g. overlapping/touching lattices.

Looking forward to your reply,
Daniel

Dear @dprelipc,

Please find attached the .inp file I am currently using.
The unit cell I intend to replicate consists of two components: the central part of the grid in vacuum, and the lateral border made of iron.
The corresponding RPPs are named "cell" and "cell_lat", and the associated regions are CELL_IN and CELL_LAT.

Regarding your suggestion of replacing the RPPs with infinite planes to improve the tracking algorithm — thank you for the idea! I’m not entirely sure I fully understood the approach, and it also seems quite complex.
If I interpreted it correctly, I would need to define 86 planes parallel to the Y-axis and 206 planes parallel to the Z-axis to describe the vacuum regions in the center, plus 2×85 and 2×205 additional planes to describe the iron layer borders, and then define each region individually using these planes. Is that correct?

Best regards,
Giorgia

aggiunte.inp (1.3 MB)

There is a conceptual flaw in your approach. In fact, you can stay with the RPPs, which do not pose subtle tracking challenges, but you need your script to generate also 17424 ROT-DEFI cards, each with the unique translation required by each lattice region, and 17424 LATTICE cards, associating to each lattice region the respective transformation. Also, note that the line
CEL1 5
has to be removed.
As an alternative, you could indeed conveniently code the lattic.f user routine, but this way you would lose the geoviewer visualization in Flair.
Another option - I’d rather recommend in view of the implied input size reduction - is to consider as basic cell a whole string of 85 elements, requiring 170 RPPs and 170 region definitions, and replicate it 204 times, by means of 204 ROT-DEFI cards, 204 LATTICE cards and 204 additional lattice region definitions.

In addition to @ceruttif’s answer, please find here for your convenience an example of a file with your basic element and a correct implementation of the lattice feature (for 2 replicas), with the associated ROT-DEFI, LATTICE and regions cards.

aggiunte_v2.inp (1.5 KB)