Notes, planning, log, etc.

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

Current problems...


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::vector grmat( 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::vector grmat( 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)

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;
      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()),

NOW I did:

  DDRotationMatrix rotation = fv.rotation().Inverse();
  DD3Vector x, y, z;
  // doesn't this just re-inverse???
  Surface::RotationType rotResult(float(x.X()),float(x.Y()),float(x.Z()),


dumb question?

is HepRotation prep() the same as ROOT::Math::DisplacementVector3D<Cartesian3D<double> > Rho()???

Really the log part... not complete, just to remind myself.

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

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2007-05-02 - MichaelCase
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback