Kinematic description in controlSurfaceTrackTypeType for different steps along path

[raedma]

• As discussed on our meeting on 26.09.2019 in VPH Bremen
• Kinematic joint description for each step defined in controlSurface path (relative coordinates with reference cruise configuration or absolute for each step)
• Number of joints dependent of chosen trackType and trackSubType elements
• Kinematic struts with profileBasedStructuralElement as connection of joints

[MarAlder]

I added a general struts and jointCoordinateSets node as discussed (5e5ee88). The name element only accepts "strut1" to "strut7" and "point1" to "point7".

Open questions from my side:

• How is the progress with the schematic drawings for the reference documentation?
• What do we do with car, sidePanels etc.?

[MarAlder]

Status

I completely reworked the controlSurfaceTrackTypeType:

More details can be found here:

• online / downloadable documentation
• CPACS tree svg

Thanks René for sending me the illustration of the tracks type. I will add it to the documentation within the next days. (Maybe we should rethink our color scheme in future versions :thinking:).

Next steps

• How do we proceed with the graphics for the remaining types? Can René quickly adopt the above drawing to have all types and sub-types you need?
• Please take a thorough look through the uploaded documentation. Does the structure correspond to what we need for a detailed description of the tracks?
• All the other structural elements (carriage, panels, attachments) are set to trackSecondaryStructureType. At the moment these only contain a reference to the material data (I think we better use a reference instead of a complete description as done before). Do we need more details here?

[MarAlder]

It's nice to see that our solution works in #623. I'll reopen the issue to track it until implementation in an official release.

[MarAlder]

For the next steps of the tracks defnition:

• current develop merged into tracks
• online / downloadable documentation

[MarAlder]

I re-opened the controlSurfaceTrackType issue due to two remaining issues from the stakeholder meeting on this topic:

To-Do before the RC:

• [ ] Definition of jointPositions
• [ ] tracks and kinematics separation

[MarAlder]

Tracks and kinematics separation

I think a separation of track & kinematik makes sense, but requires a more detailed evaluation. We would have to think about a restructuring of the nodes and how the dependencies of kinematics and trackStructure can be described, for example by uID linking. Since I got no other feedback from the community I propose to consider this for a future release and implement the revision of the figures, struts and jointPositions in the CPACS 3.3-RC. What do you think @raedma?

Joint Positions

I'm ok with replacing y with dy. What do you suggest as coordinate system? Maybe there are some best practices from the geometry community?: @rainman110, @jnwalther, @joergbrech, @sdeinert, @sfreund-DLR

[MarAlder]

Ok, change from y to dy has been implemented via 5cb8787. I propose to shift the separation of tracks and kinematics to a future relase.

[raedma]

Hi Marco, sorry, I didn't check my private GitHub account for a while. Thanks for the change. I agree, separating the kinematics from the tracks will require a little more work.

Currently we use the global aircraft coordinate system. However, the coordinate system of the section or basically any other would be fine as well. It should just be documented which coordinate system is used in the documentation.

[MarAlder]

Hi Martin, no problem; thanks for the feedback. TiGL evaluates the trailing edge boarders in the component segment coordinate system. Maybe we should do it similar for the tracks. I guess this would be more stable during aircraft sizing iterations. In future we could also add a referenceUID (see https://github.com/DLR-SC/tigl/issues/780) similar to the trailing edge devices (inner/outer boarder) if we need to choose between component segment or wing segment.

@rainman110, @joergbrech: any opinions?

If you agree I will just add it to the documentation.

[rainman110]

I agree with your suggestions. We should keep things similar. Having a referenceUID then would be the way to go.

[raedma]

Sounds good. Would the referenceUID be a mandatory field? If not, the assumption for the default behavior should be documented. And maybe an addition of the global cartesian aircraft coordinate system as referenceUID could be possible so that our colleagues @ FT are not immediately required to change their tool behavior. They currently write the joint coordinates in the global system.

Should I open another issue for the topic of separating the kinematics from the tracks?

[MarAlder]

Actually, I thought about just adding the referenceUID element in the future when there is a need to distinguish between different coordinate systems. For the current release I would just keep things simple and add a description that all coordinates refer to the component coordinate system.

Maybe it would be better if our FT colleagues could then as soon as possible switch to the component coordinate system to avoid strange geometries during wing sizing? I guess a simple repositioning of the parent wing would otherwise, for example, lead to strange distorted track structures? Maybe we can get some feedback on the implementation effort.

Added remark: The referenceUID of the control surface borders is obligatory (indicated in the documentation by Occurences being empty because [1..1] is the XML default).

[raedma]

I'll contact the FT colleagues and ask them to take a look at it

[MarAlder]

I'm about to release v3.3. I expect the current version is fine for v3.3 as there was no further feedback. Further work on the tracks can be included in upcoming releases.