TGeoShape::GetAxisRange(...) misleading for some shape

ROOT
1

Dear ROOT expert,
using TGeoShape::GetAxisRange(…) method I found a misleading behaviour.
For a TGeoBBox the constructor is:

TGeoBBox(Double_t dx, Double_t dy, Double_t dz, Double_t* origin = 0)

if I call GetAxisRange(idx,…) for a TGeoBBox object, if idx=1 I get information about x axis, if idx=2 I get information about y axis, if idx=3 I get information about z axis. This is what I expect using TGeoShape::GetAxisRange(…).

But for TGeoSphere the constructor is:

TGeoSphere(Double_t rmin, Double_t rmax, Double_t theta1 = 0, Double_t theta2 = 180, Double_t phi1 = 0, Double_t phi2 = 360)

so when I call GetAxisRange(idx,…) for a TGeoSphere object, if id idx=1 I expect to get “r” information, if id idx=2 I expect to get “theta” information, if id idx=3 I expect to get “phi” information. But in the implementation of TGeoSphere::GetAxisRange(idx,…) , if id idx=2 I get “phi” information, if id idx=3 I expect to get “theta” information.
The same happen for other shapes, for example TGeoTubeSeg. The last two variables (axis) used in the constructor are swapped in the implementation of GetAxisRange(idx,…).
I find this a little misleading, but maybe this is implemented this way intentionally for some reason unknown to me.

Cheers,
Vito

2

Hi Vito,

This is because tubes and cones have only r and phi ranges in their definition, therefore 1 became r and 2 became phi. For symmetry reasons the meaning of the first 2 parameters was kept also for sphere and the third became the theta range. The confusion comes from the association of these ranges with cartesian/polar coordinates, which was not meant at all.

Sorry for the confusion, the meaning of these ranges is in fact only shape dependent.
Cheers,

3

Hi Andrei,
it is fine. I wanted just be sure that the implementation has consistency with the other code. Of course I have to read documentation/implementation of methods to know the meanings of parameters.

Cheers,
Vito