Problem 1246 - Problem tracking particle through complex geometry--particle sees wrong material
Summary: Problem tracking particle through complex geometry--particle sees wrong material
Status: RESOLVED INVALID
Alias: None
Product: Geant4
Classification: Unclassified
Component: geometry/navigation (show other problems)
Version: 9.3
Hardware: All All
: P3 normal
Assignee: Gabriele Cosmo
URL:
Depends on:
Blocks:
 
Reported: 2011-09-01 19:41 CEST by PeterM
Modified: 2011-09-12 11:38 CEST (History)
0 users

See Also:


Attachments
"text" geometry showing the problem. (2.71 KB, text/plain)
2011-09-01 19:43 CEST, PeterM
Details
Image showing strange behavior. (7.10 KB, image/png)
2011-09-01 19:44 CEST, PeterM
Details

Note You need to log in before you can comment on or make changes to this problem.
Description PeterM 2011-09-01 19:41:28 CEST
Also, particles going in different directions apparently see different materials.  It seems like this problem may be specific to crossing specific kinds of material interfaces.  It may also be specific to the direction of the particle.

The shape involved is a pretty complex creation of Boolean geometry.  It is in the top-right corner of the enclosed png.

What is the image (StrangeBehavior.png)?  It is an image done using the OGLIX viewer in wireframe mode that I captured.  It is an edge-on view of an object that has a constant cross-section in Z.  The object is  iron (or should be.)  The "background" is made of tenuous air, basically air at low pressure.  The grid pattern are actually tracks of alpha particles, that were launched from all the "grid points" in four directions:  (+x, -x, +y, -y).  I did that so I could be *really sure* that the particles were seeing the right geometry.

I used low energy alpha particles so that they would stop quickly in any solid material, and thus show where the solid material really was.

What is really odd is that tracks can apparently proceed VERTICALLY through part of the object, HORIZONTALLY through other parts of the object, and NEITHER (as they should) in other parts of the object.

It does not seem reasonable to me to be able to construct an object of a normal material and have particles pass through it as transparent in one direction solid in the other.

I have enclosed  below a "text" geometry description of this object, which is how I input it into GEANT4.9.3p01.  Yes, the geometry is realized in somewhat of a stupid way, it was mostly automatically generated.  Yet I think it should still work.

I was unable to check if the same problem happens in GEANT4.9.4p02, because I cannot get the OGLIX viewer to work, it hangs forever apparently in some boolean calls.  But someone else has reported that bug already (I looked it up and found it.)

This problem does NOT occur if I am using simpler geometry like a straightforward box.

Below is the text description of the geometry:

// Identity Matrix
:ROTM ROT_I 1 0 0 0 1 0 0 0 1

:MIXT_BY_NATOMS TENUOUS_AIR .000000188 2 N 7 O 3

// World Volume
:VOLU world BOX 143.00011 143.00011 556.60011 TENUOUS_AIR
:VIS world OFF

// ***************************************************************
// BEGIN ASSEMBLY: Shape
// ***************************************************************

:SOLID startBooleanWorldShape BOX 130.0001 130.0001 506.0001
:SOLID modelBoundingBoxShape BOX 130.0001 130.0001 380.0001
// For possible visualization
:SOLID halfModelBoundingBoxShape BOX 130.0001 65.00005 380.0001
:SOLID translatedHalfModelBoundingBoxShape SUBTRACTION modelBoundingBoxShape halfModelBoundingBoxShape ROT_I 0 65.00005 0
//:VOLU halfModelBoundingBoxShape_A halfModelBoundingBoxShape G4_Fe
//:PLACE halfModelBoundingBoxShape_A 1 world ROT_I 0 65.00005 0

// The user may want to toggle these for visualization
:SOLID booleanWorldShape INTERSECTION startBooleanWorldShape modelBoundingBoxShape ROT_I 0 0 126
//:VOLU modelBoundingBoxShape_A modelBoundingBoxShape G4_Fe
//:PLACE modelBoundingBoxShape_A 1 world ROT_I 0 0 126


// Shape1
:SOLID Shape1 BOX 130 130 380
:SOLID B_Shape1 SUBTRACTION booleanWorldShape Shape1 ROT_I 0 0 126
//:VOLU Shape1_A Shape1 G4_Fe
//:PLACE Shape1_A 1 world ROT_I 0 0 126


:SOLID Shape2 TUBS 76.088429398 107.16680197 32.054 230.3 19.4
:SOLID B_Shape2 UNION B_Shape1 Shape2 ROT_I 75.564666984 130.88184247 0


:SOLID Shape3_0 TUBS 0 78.690532 32.054 0 360
:SOLID Shape3_1 TUBS 0 49.260806985 32.054 -17.244998891 94.489997781
:SOLID Shape3 INTERSECTION Shape3_0 Shape3_1 ROT_I 35.584717106 20.544846 0
//:VOLU Shape3_1_A Shape3_1 G4_Fe
//:PLACE Shape3_1_A 1 world ROT_I 35.584717106 20.544846 0

:SOLID B_Shape3 SUBTRACTION B_Shape2 Shape3 ROT_I 0 0 0
//:VOLU Shape3_A Shape3 G4_Fe
//:PLACE Shape3_A 1 world ROT_I 0 0 0


// Shape4
:SOLID Shape4_0 TUBS 0 78.690532 32.054 0 360
:SOLID Shape4_1 TUBS 0 49.260806985 32.054 42.755001109 94.489997781
:SOLID Shape4 INTERSECTION Shape4_0 Shape4_1 ROT_I 0 41.089692 0
//:VOLU Shape4_1_A Shape4_1 G4_Fe
//:PLACE Shape4_1_A 1 world ROT_I 0 41.089692 0

:SOLID B_Shape4 SUBTRACTION B_Shape3 Shape4 ROT_I 0 0 0
//:VOLU Shape4_A Shape4 G4_Fe
//:PLACE Shape4_A 1 world ROT_I 0 0 0


// Shape5
:SOLID Shape5 TUBS 6.985 13.97 32.054 244.78332471 102.46167418
:SOLID B_Shape5 SUBTRACTION B_Shape4 Shape5 ROT_I 32.88295028 40.247056079 0
//:VOLU Shape5_A Shape5 G4_Fe
//:PLACE Shape5_A 1 world ROT_I 32.88295028 40.247056079 0


// Shape6
:SOLID Shape6 TUBS 6.985 13.97 32.054 145.21667529 102.46167418
:SOLID B_Shape6 SUBTRACTION B_Shape5 Shape6 ROT_I 18.413497852 48.600998333 0
//:VOLU Shape6_A Shape6 G4_Fe
//:PLACE Shape6_A 1 world ROT_I 18.413497852 48.600998333 0


:VOLU B_Shape6 B_Shape6 G4_Fe
:PLACE B_Shape6 1 world ROT_I 0 0 0
Comment 1 PeterM 2011-09-01 19:43:19 CEST
Created attachment 136 [details]
"text" geometry showing the problem.
Comment 2 PeterM 2011-09-01 19:44:28 CEST
Created attachment 137 [details]
Image showing strange behavior.
Comment 3 Gabriele Cosmo 2011-09-12 11:38:56 CEST
The visualization  test you're doing is not really demonstrating the problem you report.
If the system reports errors in the visualization of the Boolean shape, the visualization itself will be likely be incorrect. This does NOT mean that the tracking will be incorrect. This has been stated several times in Hypernews and FAQs.
You should verify what gets reported in the printed log-file you get on the standard output, by setting "/tracking/verbose 1", where all real intersections get reported.
You should also additionally check any Boolean subtraction you do in your geometry and verify that there are NO shared surfaces which gets subtracted, or this will inevitably lead to situations where the volume gets 'missed' by the tracking.