Discussion: Rethink TiGL's implementation around coordinate systems and transformations

[joergbrech]

Currently, TiGL uses the CTiglRelativelyPositionedComponent to manage CPACS transformations relative to each other.

There are a few problems with the current implementation, which makes working with transformations error-prone and cumbersome.

• Not all CPACS types that come with a transformation node are implemented as CTiglRelativelyPositionedComponent, for example sections or elements. There is no single API to handle transformations and coordinate transform and every class handles it slightly differently or not at all. There are a few places in the TiGL source code, where chained transformations are performed "manually".
• CCPACSTransformation keeps a pointer to a parent CPACS node, which could be a physical component of an airplane. Conceptually, a transformation is a linear map from R4 to R4 and should be agnostic of what an airplane is. As a consequence, every time a new CPACS node is added that has a transformation, the CCPACSTransformation node must be adapted. I would argue that it is okay to keep the class as it is and live with this, as it is how the CPACS Code Generator works. But it probably makes sense to use a different transformation class for relative coordinate systems, that is convertible to and from a CCPACSTransformation.
• It is not obvious from the semantics, what the transformation of a relatively positioned component does: Does it transform sth from global coordinates to local coordinates or vice versa? Does it transform sth from the parent coordinate system to the local coordinate system or vice versa?
• It would be very useful to have an interface for different types of coordinate systems, i.e. cartesian, cylindrical and spherical coordinates.

Proposal:

• Create a new transformation class, or re-use CTiglTransformation. This class stores a private 4x4 matrix as the raw transformation and a pointer/optional to a parent transformation. With this, it should be possible to build a tree of coordinate systems. We should somehow guard against circular references.
• The new Transform class provides methods along the lines of Vector from(Vector const& x, Transform const& origin_transform) to transform a vector defined in the coordinate system origin_transform to local coordinates and Vector to(Vector const& y, Transform target_transform) to transform a vector defined in local coordinates to the coordinate system target_transform.
• In addition, it could provide some convenience functions for transforming to and from the parent and to and from the global coordinate system.
• There should be ctors, getters and setters for different kinds of coordinate systems (cartesian, cylindrical, spherical)

This would be a big refactor in TiGL, but I think the effort is worth it.

@rainman110, tagging you here because I remember we had a discussion about this quite a while back and never found the time to follow up on it. @AntonReiswich, any thoughts?

[rainman110]

I can still pretty much recall most of the details from our discussions.

We had two classes

• CoordinateTransform, containing basically a 4x4 transformation matrix
• CoordinateSystem, consisting of a CoordiateTransform and an optional parent CoordinateSystem

This basically defines a tree of coordinate systems, starting at the root coordinate system.

This enables us to create a function like

template <typename T>
T transformCoordinates(CoordinateSystem fromSystem, CoordinateSytem toSystem, T toTransform);

This allows to transform between all kinds of coordinate systems.

In addition, a cpacs node like CCPACSWing contains a coordinate system, making it explicit which coordinate system is the local system.

A RelativelyPositionedComponent actually contains two coordinate systems (a translation only system and the local system also including the rotation), to allow the cpacs way to deal with rotations and translations, since it is only translated according to the parent component but not using its rotation.

This would be some pseudo code of the RelativelyPositionedComponent class:

struct CoordinateSystem
{
    CoordinateSystem();
    CoordinateSystem(Transformation);
    CoordinateSystem(CoordinateSystem parent, Transformation);
};

struct RelativelyPositionedComponent
{ 
  RelativelyPositionedComponent(RelativelyPositionedComponent parentComponent)
    : localTranslation(parentComponent.localTranslation, myCpacsTransformation.translation)
    : local(localTranslation, myCpacsTransformation.rotation)
  {}

   CoordinateSystem localTranslation;
   CoordinateSystem local;
};

Hence, the coordinate system RelativelyPositionedComponent references only to the translational coordinate system of its parent, not to the parent local system.

[AntonReiswich]

I will think about it and get back to you!