# CombGeometry refactoring bug?

From: Popescu, Razvan <popescu_at_bnl.gov>
Date: Tue, 9 Jul 2013 19:29:09 +0000

Dear developers,

I have attached a simplified illustration of an anomaly(?) I have encountered in a production simulation which uses extensively transformations (rotations and translations) of bodies to create more complex geometries. I was able to reproduce the "anomaly" with a very simple case, which you can find attached.

In this example a very simple shield is formed by bringing together two iron blocks - one of them is put in place by a translation, while the other is created already in the final position. The translated block is also the result of cutting a larger block by a plane (to create the proper final shape).
In my case, both elements are necessary to create the "anomaly" : the use of transformations and the use of a body with adjacent "air", which will have to be added back with a particular geom. combination.

The latter geometry formulation while in this simple geometry would seem unnecessarily complicated, comes very handy in the original production case, where I need to shape a complex object by cutting its faces from a larger parallelepiped, using planes at proper angles. To limit the complexity of the region definitions, I subtract the main "coarse" parallelepipeds from the main void and following, I add detailed additional void regions made up by subtracting the finished "shaped" objects from the respective "coarse" blocks. The same logic is reproduced in the attached simplified example.

The input has two versions of the critical card defining the "VOID1" region:

1) "CASE1 - FAULTY" (card comment) uses: " VOID1 = wall1 -( wall1 +pl1) -wall2 " simulating the logic above - take the "coarse" body and subtract the "shaped" core, and in addition must subtract the sub-region(s) that overlaps with other bodies This last component makes the use of transformation critical in triggering this behavior, as the overlap occurs only in transformed bodies/sub-regions

2) "CASE2 - CORRECT" uses the refactored version of the above definition (wall1 - pl1 - wall2) and works correctly!

Employing CASE1 card creates a geometry with a gap in the shield!

Flair misses the error (!!) and its geometry editor displays a contiguous iron shield as the user would normally expect.

However, FLUKA reveals the problem as the "green" projection shows a different picture, with the gap in the middle. Particle scoring behind the shield confirms the gap in the structure.

The "out" file shows that the parsed input is very different (!!!) that what I'd expected: VOID1 is parsed to only "wall1 -pl1" explaining the gap.

On the other hand, CASE2 card version is parsed correctly and produces the proper results.

To add to my confusion, shifting the two blocks relative to each other, along the Z axis, prevents the mistaken parsing even when using CASE1 card...

(Fluka2011 v.2.17 Dec-12 ; Flair v.1.1.1 R2346)

Am I missing something embarrassingly simple here ?... :)

Thanks,

Razvan Popescu

• application/octet-stream attachment: SRinj.inp
Received on Tue Jul 09 2013 - 22:33:18 CEST

This archive was generated by hypermail 2.3.0 : Tue Jul 09 2013 - 22:33:24 CEST