Difference: CMSMECDetectorDescriptionToROOTMath (1 vs. 4)

Revision 42007-05-02 - MichaelCase

Line: 1 to 1
 
META TOPICPARENT name="CMSMECDevBlog"

Notes, planning, log, etc.

Line: 19 to 19
  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?
Changed:
<
<
Is this correct? Change:
>
>
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++) {

Line: 49 to 49
  HepTransform3D(fv.rotation(),fv.translation()));
Changed:
<
<
How about...
>
>
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...

Line: 106 to 106
 

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

Added:
>
>
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.

Revision 32007-05-02 - MichaelCase

Line: 1 to 1
 
META TOPICPARENT name="CMSMECDevBlog"

Notes, planning, log, etc.

This is to allow others to see what I'm doing and planning.

Added:
>
>
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
Changed:
<
<
HepRotation ROOT::Math::Rotation3D This is done with a typedef. The trick with at typedef is to use the functionality of the thing that is typedeffed but still call it by the typedef name. The functionality provided is the same but methods may change and so in effect the interface will change. The 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.
>
>
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
Line: 47 to 49
  HepTransform3D(fv.rotation(),fv.translation()));
Added:
>
>
How about...

//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));

DTGeometryBuilderFromDDD

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

Miscelaneous...

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 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.

Revision 22007-05-02 - MichaelCase

Line: 1 to 1
 
META TOPICPARENT name="CMSMECDevBlog"
Changed:
<
<

2007

>
>

Notes, planning, log, etc.

 
Changed:
<
<
May 1: Geometry packages using DDAlgorithms have been updated to make sure they conform to the Detector Description's new use of ROOT::Math::Rotation3D.
>
>
This is to allow others to see what I'm doing and planning.
 
Changed:
<
<
April 30: 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.
>
>
Migration from CLHEP to ROOT::Math.

Existing Migration to Comments
HepRotation ROOT::Math::Rotation3D This is done with a typedef. The trick with at typedef is to use the functionality of the thing that is typedeffed but still call it by the typedef name. The functionality provided is the same but methods may change and so in effect the interface will change. The 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.
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

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?

Is this correct? Change:

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

EcalBarrelGeometryLoaderFromDDD

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

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

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

Revision 12007-05-01 - MichaelCase

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="CMSMECDevBlog"

2007

May 1: 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: 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

 
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