This is to allow others to see what I'm doing and planning.
Summary: There are many changes in Geometry caused by converting DetectorDescription to ROOT::Math. The best way for these changes to be made is for the original authors of the code to work on them. Below I've detailed how I managed to get some of the failures in Geometry to compile but I do not know whether they do exactly what the author wants (wanted from DD/CLHEP).
Migration from CLHEP to ROOT::Math.
Existing | Migration to | Comments |
HepRotation | ROOT::Math::Rotation3D | This is done with a typedef. The "trick" in using a typedef is that the developer(user) needs to use the functionality of the thing that is typedeffed but still call it by the typedef name. The developer must rely on the functionality provided by the new typedef being the same but in this case (and probably most such means of "abstracting" an interface) methods may change and so in effect the interface will change out from under the developer(user). Another alternative (if you want) is NOT to typedef in the DetectorDescription but rather let users use the original type everywhere. I believe the typedef is useful, though not perfect. Another alternative is to create a VERY simple class that USES as a private member the rotation implementation we want. And finally, another alternative would be to inherit from the one we want and implement changes as needed, but i don't like this one... gut-wise. |
Hep3Vector | ROOT::Math::DisplacementVector3D<Cartesian3D<double> > CHECK THIS, its from memory | |
------ | ROOT::Math::AngleAxis | This is needed because in the CLHEP one could create a HepRotation by providing a vector (3 points) and a number and rotate around the vector (axis) a given angle (the number). No such constructor for ROOT::Math |
CSCGeometryBuilderFromDDD has a line like this HepRotation::HepRotation_row r = fv->rotation()[i]; which assumes the row function of CLHEP HepRotation. So how do I change this?
Does this change do what is intended? I changed this:
std::vectorgrmat( 9 ); // set dim so can use [.] to fill for (size_t i = 0; i < 3; i++) { rotindex = i; HepRotation::HepRotation_row r = fv->rotation()[i]; size_t j = 0; for (; j < 3; j++) { grmat[rotindex] = (float) 1.0 * r[j]; rotindex += 3; }
To this:
std::vectorgrmat( 9 ); // set dim so can use [.] to fill fv->rotation().GetComponents(grmat.begin(), grmat.end());
What to do with this?
// rotate the trapezium and then move it theGeometry->hepTransform(HepScale3D(0.1) * // convert from mm (DDD) to cm (G3) HepTransform3D(fv.rotation(),fv.translation()));
How about... [to be more precise I convert from the ROOT::Math in the DDD to CLHEP objects so that the call to hepTransform still works]
//BRUTE FORCE conversion from CLHEP to ROOT::Math in DDD... DD3Vector x, y, z; fv.rotation().GetComponents(x,y,z); Hep3Vector hx(x.X(), x.Y(), x.Z()); Hep3Vector hy(y.X(), y.Y(), y.Z()); Hep3Vector hz(z.X(), z.Y(), z.Z()); HepRotation hr (hx, hy, hz); Hep3Vector h3v(fv.translation().X(), fv.translation().Y(), fv.translation().Z()); HepTransform3D ht3d(hr, h3v); theGeometry->hepTransform(HepScale3D(0.1) * // convert from mm (DDD) to cm (G3) HepTransform3D(hr, h3v));
Also, I want to ask if this code does the inversion of the matrix twice or what exactly it does
Here is before:
// now the rotation DDRotationMatrix tmp = fv.rotation(); // === DDD uses 'active' rotations - see CLHEP user guide === // ORCA uses 'passive' rotation. // 'active' and 'passive' rotations are inverse to each other DDRotationMatrix rotation = tmp.inverse(); Surface::RotationType rotResult(float(rotation.xx()),float(rotation.xy()),float(rotation.xz()), float(rotation.yx()),float(rotation.yy()),float(rotation.yz()), float(rotation.zx()),float(rotation.zy()),float(rotation.zz()));
NOW I did:
DDRotationMatrix rotation = fv.rotation().Inverse(); DD3Vector x, y, z; rotation.GetComponents(x,y,z); // doesn't this just re-inverse??? Surface::RotationType rotResult(float(x.X()),float(x.Y()),float(x.Z()), float(y.X()),float(y.Y()),float(y.Z()), float(z.X()),float(z.Y()),float(z.Z()));
dumb question?
is HepRotation prep() the same as ROOT::Math::DisplacementVector3D<Cartesian3D<double> > Rho()???
May 2, 2007: After the meeting it is my impression that Vincenzo will take the tar file into a full CMSSW nightly and see whether any subsystem outside Geometry and DetectorDescription are affected by the changes in the tar file I provided.
May 1, 2007: Geometry packages using DDAlgorithms have been updated to make sure they conform to the Detector Description's new use of ROOT::Math::Rotation3D.
April 30, 2007: As of this date all DetectorDescription packages have been migrated (again) following Vincenzo Innocente's first migration and copying a lot of what he had done.
-- MichaelCase - 01 May 2007
Webs
Welcome Guest