Explicit specification of geometric symmetry

[MarAlder]

We do have the problem that we don't have a consistent interpretation of the symmetry attribute in CPACS. I would like to discuss the following proposal.

We could introduce a new attribute symmetryType, which can have the following values:

• mirroredExtension (e.g., a wing which will remain a single component)
• mirroredCopy (e.g., a rotor which is mirrored and treated as a new component, see picture below)
• translatedCopy (e.g., a rotor which has a symmetric counterpart on the other wing but rotating in the same direction; does not yet exist in CPACS)

Two examples for copies (or should we name it dublicates?):

This way the symmetry attribute would still define the symmetry plane (I swapped it into a restricted xsd:string simpleType) and "old" data-sets would remain valid in TiGL. With the additional symmetryType attribute (don't confuse the attributes name with the symmetryType for the symmetry element) tools would know how to properly treat the geometry. The symmetry attribute is part of the following elements and I added the symmetryType attribute with the default value corresponding to the way we previously treated the symmetry:

• enginePositionType

  • mirroredCopy (default)
  • translatedCopy

• enginePylonType

  • mirroredCopy

• fuselageType

  • mirroredExtension
  • mirroredCopy (default)

• wingType

  • mirroredExtension (default)
  • mirroredCopy

• mainGearType / skidGearType / noseGearType

  • mirroredCopy

• guideCurveProfileGeometryType

  • mirroredExtension

• geogenWingOutputOptionsType

  • no changes here (it's an element)

• rotorType

  • mirroredCopy (default)
  • translatedCopy

• profileGeometryType

  • mirroredExtension

• profileGeometry2DType

  • mirroredExtension

• genericGeometricComponentType

  • mirroredCopy (default)
  • translatedCopy

• genericSystemType

  • mirroredCopy (default)
  • translatedCopy

Do we need the attribute if only one option is possible? Maybe it is then more specify in the schema (and documentation).

[joergbrech]

@MarAlder, @cliersch, @AntonReiswich, @svengoldberg, @merakulix and I had a discussion on how we want to deal with symmetries in CPACS and TiGL in the (near) future. Here are the "minutes":

• For now, we interpret the existing symmetry attribute in such a way, that the geometric component with a defined symmetry plane will have a mirrored copy along the symmetry plane (e.g. an engine nacelle gets copied to the other side). We do not interpret it in the sense that a geometric component with a symmetry attribute is a single entity with a geometric symmetry defined (e.g. half-body)

• We decided to keep the symmetry attribute as is for now, which allows disabling the inheritence of symmetry from a parent. This way, children of geometric components with a symmetry plane will inherit the symmetry plane by default, unless the inheritence is explicitly disabled. This could e.g. be used to define symmetric engines, but with asymmetric rotors that rotate around the same axis. We need to properly document in CPACS what is meant by parent (in terms of hierarchical xpath parent or parent as given by the parent uid and which takes precedence). This functionality is already fully supported by TiGL.

• The symmetry attribute will not generally be added to all cpacs nodes that represent a geometry, if it is not there yet. It will be added on a use-case basis depending on the needs of the CPACS users.

• We propose to use the symmetry attribute of the parent UID element for referencing parents on a symmetric part (e.g. an object that exists only on the mirrored copy). We propose to remove the "full" option and just keep "sym" to reference the symmetric copy of the object with a given uid, or "def" to reference the defined part of the object with the given uid. This is not yet supported by TiGL, see also this TiGL issue. The name of the attribute symmetry of the parentUID as well as the two values sym and def are still to be discussed.

• We discussed to optionally add convenience functions to TiGL:

   - Functions returning a cardinality such as GetSegmentCount will only return the cardinality of the defined part. It does not make sense to add functions that return the cardinality of a symmetric copy, or of “both parts” in total. This prevents out-of-bounds errors or index ambiguities when iterating. As an example, a simple configuration with symmetric main wing and HTP and non-symmetric VTP will continue to have a wing count of 3 and not 5. This is the status quo in TiGL and will not change.     - Functions returning UIDs will not be changed.      - Functions to query geometric information on symmetric parts could be modified for convenience, by adding an enum "Symmetry" which has the values "sym" and "def" (in analogy to the symmetry attribute of the parentUID element). Functions such as CPACSWing::GetPoint(...) would get an optional last argument CPACSWing::GetPoint(..., Symmetry=def). These functions would just transform the result based on the symmetry property of the queried object and the passed argument.

• We identified three test cases to help us understand the limitations and intricacies:   1. A trimmed control surface defined as a child of a symmetric wing,   2. a hybrid electrical configuration with a gas turbine on one wing and a battery on the other and   3. a spar that exists in the defined wing but not the symmetric wing or vice versa

[MarAlder]

@MarAlder, @CLiersch, @AntonReiswich, @svengoldberg, @merakulix, @sdeinert and @rmaierl had a follow-up discussion:

• [x] Agreed: The application of the symmetry attribute leads to a new component.
• [x] Examples for control surface, gas turbine, and engine pepared. Result: Concept of using the symmetry attribute for elements with a parentUID works well. It needs for each case to be decided and documented what exactly parentUID means and where we need to assign the symmetry attributes.
• [x] TiGL functions will be individually documented as to whether they refer only to the defined part (e.g. counting of wing segments), or whether they also include the symmetric part (e.g. determine the wing span). Additionally, we will consider adding an attribute like symmetry=def to explicitly enable TiGL functions to handle the defined or symmetric part.
• [ ] ToDo: Check application cases spar, cell, and other structural elements which do not have a parentUID. @sdeinert @rmaierl
• [ ] ToDo: Check application cases in the analyses node. @cliersch
• [ ] ToDo: propose to remove the possibility to mirror a half-fuselage because this conflicts with the upper assumption.
• [ ] ToDo: Decide whether we want to continue allowing default parameters for the symmetry attributes or enforce them explicitly.
• [ ] ToDo: Depending on the upper point, symmetry="full" should be removed if we continue with default values (because this is the default behavior anyway). Else, it will be kept.
• [ ] Renaming: Should the referencing symmetry attribute be renamed or not? E.g., side, symmetryRef, ...
• [ ] Renaming of the keywords: symmetry="full" -> symmetry="both"?