Message: Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation 

Forum: Geometry
Re: Question Trouble with G4SubtractionSolid -- pipe at angle to wall (Michael H. Kelsey)
Re: Idea Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation (Michael H. Kelsey)
Re: None Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation (Tom Roberts)
Date: 15 Jan, 2011
From: Michael H. Kelsey <Michael H. Kelsey>

Tom Roberts writes:
> I have not checked your values, but as the CLHEP routines have been used
> by many people for many years, it is unlikely that you have actually
> found a bug. More likely is that you are confused by their rotation
> conventions. So I urge you to study the documentation carefully.

Hi, Tom.  Yes, I agree with you, and I should have been more clear about my
doubts that this is really a software bug, versus (I think?!?) ambiguous or
possibly inaccurate documentation.  Thank you very much for taking the time
to follow up with me; I really appreciate it.

> I remark that rotation conventions can be VERY confusing.

Yes, they are.  And as I recall from my (two decades ago :-) differential
geometry class, it seems like no two authors use the same conventions,
either :-/

> I decided that CLHEP and Geant4 used an overly-confusing definition, so I
> invented my own convention and implemented it using a sequence of single
> CLHEP rotations:
> 
>     In G4Beamline, all rotations are specified relative to the fixed
>     coordinate axes of the parent volume into which a given element is
>     being placed. This is the natural way to think of placing an
>     object into a room, where the object is the element being placed,
>     and the room is the parent volume into which it is placed.
> 
>     -- http://www.muonsinc.com/g4beamline/G4beamlineUsersGuide.pdf
>        section 2.5
> 
>     A user specifies a rotation as a string like this: "X90,Y45" -- 
>     rotate the object 90 degrees around the parent's X axis, then 45 
>     degrees around the parent's Y axis.

And that is exactly what the comments in CLHEP/Vector/Rotation.h seem to
describe:  rotateY is a rotation of the input object (e.g., a vector) about
the external Y axis, and so on.

> Note this is completely different from CLHEP and Geant4, and my code is
> usually calling inverse() of rotation matrices, and using right
> multiplication to apply a sequence of rotations from the world through
> ancestor volumes to daughter volumes. In extensive testing of my code I
> found no errors in any CLHEP rotation routines, but I generate all
> rotations by calling only CLHEP::HepRotation{XYZ} and multiplying them
> together myself.

Ah, ha!  You've just confirmed my suspicions, and it sounds like it's just a
case of convention confusion.  What you say, "using _right_ multiplication
to apply a sequence of rotations" is exactly what I encountered myself.  At
least I wasn't doing something wrong, just not understanding properly.

> Visualization is your friend when debugging rotations. but beware of
> bugs in visualization of boolean solid operations, so test the bare
> solids first.

Yes.  I've read through a number of postings in the Hypernews about vis
problems with Boolean.  So far, I think my geometry has been simple enough
(cylindrical penetrations through either planes or cylindrical shells) that
I've been able to use the pictures confidently.

      -- Mike

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 None: Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation   (Joseph Perl - 15 Jan, 2011)
 Add Message Add Message
to: "Re: Trouble with G4SubtractionSolid -- bug? in CLHEP::HepRotation"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]