implement ducts

[AntonReiswich]

• add CPACS schema to TiGL repo https://github.com/DLR-SL/CPACS/tree/ducts
• generate code with code generator
• make sure newly generated code compiles
• define test geometries and unit tests
• implement geometry
  • Write BuildLoft for CCPACSDuct that uses CTiglMakeLoft for outer geometry and recycles fuselage structure code for the duct structure
  • Add option to get shape with duct cutout for CCPACSWing, CCPACSFuselage, CCPACSWingStructure and CCPACSFuselageStructure. To Do: What should be the default shape? With duct cutout or without?

[MarAlder]

I see you are already busy implementing the ducts. We recently worked together on this proposal for a corresponding scheme:

It's just going through my mind: We wanted to create multiple duct elements like a fuselage, then fuse them and cut the resulting ductAssembly out the parent structure. Does this cause problems when defining the inner structure (ribs and spars)? And what happens if the individual duct elements don't overlap/connect?

From a CPACS point of view we have the flexibility to use multiple elements within a section. This could also be used to define multiple segments reusing the same elements:

<segment>
    <name>segment1</name>
    <fromElementUID>sec1Element1</fromElementUID>
    <toElementUID>sec2Element1</toElementUID>
</segment>
<segment>
    <name>segment2</name>
    <fromElementUID>sec1Element2</fromElementUID>
    <toElementUID>sec2Element1</toElementUID>
</segment>
<segment>
    <name>segment3</name>
    <fromElementUID>sec2Element1</fromElementUID>
    <toElementUID>sec3Element1</toElementUID>
</segment>

The question is certainly how to deal with tangent continuity in Section2, so I intentionally did not remove the two overlapping curves in segment3 for once. A challenge would also be that it drastically changes the lofting algorithm, I guess.

Maybe a stupid idea, as also in CPACS we assume that lofting is along the sequence of the segments. But anyway, I just want to share these thoughts. Maybe it will inspire one or two ideas for a solution.

[joergbrech]

Thanks @MarAlder for your comments and help pushing this definition forward!

Does this cause problems when defining the inner structure (ribs and spars)?

Yes, probably. We haven't started implementing the duct structure yet, so I can't say for certain. We could argue, that the author of the CPACS file is responsible for this: If they define overlapping ducts, they should have an idea how this effects the inner structure.

And what happens if the individual duct elements don't overlap/connect?

In this case, a DuctAssembly just represents a collection of nonoverlapping duct elements. I think this could also be useful to define sets of ducts for individual components. From an implementation perspective, this is no problem.

The question is certainly how to deal with tangent continuity in Section2, so I intentionally did not remove the two overlapping curves in segment3 for once.

The nice thing is, that we have control over the continuity and tangents by defining dummy guide curves. We can actually prescribe the tangents and continuity conditions at this section and our current CPACS file for unit testung already uses this functionality:

Here, the "Y-Duct" assembly in red is defined as a single duct element with symmetry flag and guide curves to describe the tangents at the second section. See the tangent and continuity nodes:

tigl/tests/unittests/TestData/simpletest_ducts.xml

Lines 1651 to 1702 in 6c8d046

	<segments>
	<segment uID="segmentD150_Duct_9Segment2ID">
	<name>D150_Duct_9Segment2</name>
	<fromElementUID>D150_Duct_9Section1IDElement1</fromElementUID>
	<toElementUID>D150_Duct_9Section2IDElement1</toElementUID>
	<guideCurves>
	<guideCurve uID="Duct_9_upperGuideCurveSegment1">
	<name>sDuct_9_upperGuideCurveSegment1</name>
	<guideCurveProfileUID>dummyGuideCurveProfile</guideCurveProfileUID>
	<fromRelativeCircumference>0.</fromRelativeCircumference>
	<tangent>
	<x>1.</x>
	<y>0.</y>
	<z>0.</z>
	</tangent>
	<toRelativeCircumference>0.</toRelativeCircumference>
	</guideCurve>
	<guideCurve uID="Duct_9_lowerGuideCurveSegment1">
	<name>Duct_9_lowerGuideCurveSegment1</name>
	<guideCurveProfileUID>dummyGuideCurveProfile</guideCurveProfileUID>
	<fromRelativeCircumference>0.5</fromRelativeCircumference>
	<tangent>
	<x>1.</x>
	<y>0.</y>
	<z>0.</z>
	</tangent>
	<toRelativeCircumference>0.5</toRelativeCircumference>
	</guideCurve>
	</guideCurves>
	</segment>
	<segment uID="segmentD150_Duct_9Segment3ID">
	<name>D150_Duct_9Segment3</name>
	<fromElementUID>D150_Duct_9Section2IDElement1</fromElementUID>
	<toElementUID>D150_Duct_9Section3IDElement1</toElementUID>
	<guideCurves>
	<guideCurve uID="Duct_9_upperGuideCurveSegment2">
	<name>sDuct_9_upperGuideCurveSegment2</name>
	<guideCurveProfileUID>dummyGuideCurveProfile</guideCurveProfileUID>
	<fromGuideCurveUID>Duct_9_upperGuideCurveSegment1</fromGuideCurveUID>
	<continuity>C2 to previous</continuity>
	<toRelativeCircumference>0.0</toRelativeCircumference>
	</guideCurve>
	<guideCurve uID="Duct_9_lowerGuideCurveSegment2">
	<name>Duct_9_lowerGuideCurveSegment2</name>
	<guideCurveProfileUID>dummyGuideCurveProfile</guideCurveProfileUID>
	<fromGuideCurveUID>Duct_9_lowerGuideCurveSegment1</fromGuideCurveUID>
	<continuity>C2 to previous</continuity>
	<toRelativeCircumference>0.5</toRelativeCircumference>
	</guideCurve>
	</guideCurves>
	</segment>
	</segments>

That being said, TiGL doesn't let you define a single "branching" fuselage/duct, as in you example, though I am actually not sure what happens if you try. I would have to check.

Finally, do you think we should open an issue over at DLR-SL/CPACS so that the community can comment on the current proposal?

[rainman110]

Awesome work guys 😄