Problem 936

Summary: a boolean of two TRAP and one TUBS is not properly visualized
Product: Geant4 Reporter: Pedro.Arce
Component: visualization/modelingAssignee: John.Allison
Status: RESOLVED LATER    
Severity: major CC: John.Allison
Priority: P5    
Version: 8.2   
Hardware: PC   
OS: Linux   
Attachments: geometry class and two .wrl files

Description Pedro.Arce 2007-04-16 21:46:34 CEST
Created attachment 1 [details]
geometry class and two .wrl files

We are doing a union of a TRAP and a TUBS plus an intersection of this with another TRAP and it is wrongly visualized. Indeed the effect is quite strange: 
I am attaching a geometry with 3 solids like that. 
The solid in the middle is wrongly visualized while the first and the third are OK. 
Then I build the second logical volume using the same solid of the first one (look at line testBEAM2G4geom.cc:143, G4bool bA0repeated, to run easily both cases). In this case the first two solids are OK, but then the third one is wrong!

In summary changing the second volume changes the visualisation of the third. 

I also tested that the tracking is indeed correct, and the same for both cases.

I am attaching the detector class and the two examples of .wrl files.
This is quite important for us, because we see other very strange effects and we cannot debug our geometry. 

Pedro
Comment 1 John.Allison 2007-04-18 12:33:10 CEST
Dear Pedro,

I have had a look at your code.  I will continue to investigate.

For now, I can say that I partially understand why setting bA0repeated=true removes the problem from the 2nd volume.  Since, in that case, the second volume has the same logical volume as the first, there is no attempt to recreate the polyhedron - it is cached by the solids.

What I do not understand is why the third solid, which seems OK when bA0repeated==false, fails when bA0repeated==true.  It seems that the second attempt to create a polyhedron fails, but a third succeeds on a volume that previously failed.  It seems that the polyhedron class has a memory of previous usage.

You will notice in both cases that you get the message:
BooleanProcessor::triangulateContour : could not generate a triangle (infinite loop)
BooleanProcessor: boolean operation failed
I will now try to understand why this is happening and see if the recovery procedure is sensible.

Cheers, John.
Comment 2 John.Allison 2007-04-18 17:18:08 CEST
OK.  I have an understanding and a workaround.

The Boolean Processor (BooleanProcessor.src in graphics_reps/src) has a memory which is part of a workaround for coincident surfaces (see ll.1762-1856).  For some reason, this is not working for your case.

I have two workarounds for you:

1) Add an insignificant translation to the G4UnionSolid, e.g:
  new G4UnionSolid("MLCQ_TEST_A_LEAF_TUBS_2",MLCQ_LEAF_A2_solid,MLCQ_TUBS_A2_solid,R_y90,G4ThreeVector( 0.001, -9.001,  0.001 ));

2) Think of a new way of making the solid that involves fewer coincident surfaces.  For example, make an intersection of a "LEAF" and a G4Tubs and a union with a smaller "RLEAF" positioned adjacent.

This issue with the Boolean Processor is ongoing.  We are looking for solutions but it is an extremely complex computational problem.