Problem 10 - incorrect OPACS vizualization for a special case of geometry with rotations matrices
Summary: incorrect OPACS vizualization for a special case of geometry with rotations m...
Status: CLOSED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: visualization/OPACS (show other problems)
Version: 0.1
Hardware: HP HP-UX
: P2 normal
Assignee: barrand
URL: /afs/cern.ch/user/i/ivana/public/g4vi...
Depends on:
Blocks:
 
Reported: 1999-09-02 05:08 CEST by Ivana.Hrivnacova
Modified: 1999-10-18 11:03 CEST (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this problem.
Description Ivana.Hrivnacova 1999-09-02 05:08:26 CEST 
We are getting in a special case of our geometry
 different pictures with OPACS and DAWN visualization.
 I extracted this special case into ExN02
 and reproduced the problem within this example.
 I've put this modified  ExN02DetectorConstruction.cc
 together with the output (pictures & texts) into

 /afs/cern.ch/user/i/ivana/public/g4visualization

 The geometry is following:
 12 boxes are put into a tube (positioned twice - once with
 rotation) that is placed in another tube (unrotated).
 In case when rotation matrices are defined in
 "a Geant3 way" (from the polar/azimuthal angles
 of the axis of the rotated reference system)
 the pictures from OPACS and DAWN are different:
 DAWN is ok (dawn.eps), OPACS gives wrong picture (opacs.ps).
 In case when rotation matrices are defined in
 "a Geant4 way" both pictures are the same (and
 correct).

 The rotation matrices defined in the two ways differ
 only within a computing precision (see output_g3matrixdef and
 output_g4matrixdef) => they should give the same geometry
 - what is true for DAWN pictures but not for the OPACS.
 It seems that OPACS does not work well when
 rotation matrices contain small non-zero elements instead
 of 0.
Comment 1 barrand 1999-10-04 03:11:59 CEST 
I hope to look at it this week...
Comment 2 barrand 1999-10-04 03:14:59 CEST 
Oups, first step in the this tracking bug system. Let us try again to change the
status of this bug.
Comment 3 barrand 1999-10-04 03:15:59 CEST 
let us try again to change the status of this problem...
Comment 4 barrand 1999-10-04 03:19:59 CEST 
Try again...
Comment 5 John.Allison 1999-10-04 03:20:59 CEST 
This time *I* will try (John).
Comment 6 barrand 1999-10-11 10:04:59 CEST 
First investigations shows that
 it is NOT an OPACS problem.

  The fact that DAWN do not see the problem
 comes to the fact that both drivers do not
 pass in the same code in the Geant/visualisation
 to draw a Box.
 For OPACS at one moment I have to set the
 matrices from the Geant4 one. For that I need
 to extract (angle, axis) for rotation, to do that
 I am doing a :

   transformation.getRotation().getAngleAxis(angle,axis);

 and it appears that the angle is "NaN" !!!!!!!!

  I have done the same extraction/dump in
 vis/modeling/G4PhysicalVolumeModel.cc/DescribeAndDescend
 and I have the same !!! Then clearly the problem
 is not on my side. I strongly suspect that
 CLHEP/Rotation/getAngleAxis is wrong.

  It appears that I am the only one in
 all the Geant4 code that uses this function...

  I am going to try to debug CLHEP...
Comment 7 barrand 1999-10-12 03:19:59 CEST 
I have modified the logic of computing
 the matrix for the OPACS/Go driver in order
 to avoid the CLHEP Rotation.getAngleAxis function.

  It seems ok now on Ivana example and on others.

  In fact it should be more efficient now.

  I will notify the CLHEP people about the getAngleAxis
 precision problem when angle is PI. Some acos(-1) is done
 that produces a NaN answer (Linux and NT) !!!!
Comment 8 barrand 1999-10-18 09:52:59 CEST 
Try to set CLOSED again.
Comment 9 barrand 1999-10-18 09:59:59 CEST 
Try to set CLOSED without any Resolution !