Problem 10

Summary:	incorrect OPACS vizualization for a special case of geometry with rotations matrices
Product:	Geant4	Reporter:	Ivana.Hrivnacova
Component:	visualization/OPACS	Assignee:	barrand
Status:	CLOSED FIXED
Severity:	normal	CC:	Ivana.Hrivnacova, John.Allison, stanaka
Priority:	P2
Version:	0.1
Hardware:	HP
OS:	HP-UX
URL:	/afs/cern.ch/user/i/ivana/public/g4visualization

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 !