visualize tank geometry in tigl, apply fuselage methods for it

[sfreund-DLR]

Hi, with the new cpacs tank definition finalized, I'd like to request tigl support for it. The tank geometry is defined alike the fusealge geometry starting at the "hulls"-element. These would be the requested items

• visualize the tank in tigl viewer
• provide the tigl-fuselage alike methods for the tank

An examplary cpacs dataset is under development and will be added when finished.

This is an examplary view of an aircraft with tanks

[MarAlder]

The implementation of the tanks in TiGL is nearing completion (the figure above shows the TiGL implementation of a highly simplified tank (but using the fuselage approach) with two hulls (green) in a fuselage (blue)). I am still working on the transfer of some fuselage operations. @sfreund-DLR, would you provide a (Python) prototype for calculating the geometry according to the simplified parameters, ideally with pythonOCC?

Note that I moved the transfomation element one level higher.

[MarAlder]

Linking the Python prototype for designParmeters: tanks.zip

[MarAlder]

I propose to restructure the schema so that we can define the designParameters as an alternative to segments and sections. This makes it possible to define multiple hulls via the simplified approach. Furthermore, all other elements (structure, cutOuts, maybe buffels/walls) can be used in the same way for both approaches. The schema also looks cleaner. Disadvantage: The order of the elements must be adhered to (choice elements unfortunately force xsd:sequence).

What do you think, @sfreund-DLR?

[sfreund-DLR]

good idea!

[MarAlder]

TiGL philosophy question: The third ellipsoid dome in this example has a negative half-axis fraction. Should we: (1) set the values to the next reasonable values (values <0 to =0; values >1 to =1), throw a warning, and build the geometry, or (2) throw an error and not build the geometry?

Currently I implemented the first approach:

                    <hull uID="genericTank3_ellipsoidDome2">
                      <name>Hull with ellipsoid dome</name>
                      <description>This hull has an invalid halfAxisFraction. It is used for testing of exeption handling.</description>
                      <transformation>
                        <translation>
                          <x>1</x>
                        </translation>
                        <scaling>
                          <x>1</x>
                          <y>0.7</y>
                          <z>0.7</z>
                        </scaling>
                      </transformation>
                      <cylinderRadius>1.0</cylinderRadius>
                      <cylinderLength>2.0</cylinderLength>
                      <domeType>
                        <ellipsoid>
                          <!-- This should throw a warning and be set to 0 -->
                          <halfAxisFraction>-0.2</halfAxisFraction>
                        </ellipsoid>
                      </domeType>
                    </hull>

Note: I can, of course, catch some invalid values via XSD, but in other cases it becomes impossible (e.g., combination of the two radii for the torispherical dome)

[joergbrech]

@MarAlder I think your approach of throwing a warning is fine. I usually try to follow two rules of thumb and find a good compromise:

• Robustness: TiGL should ideally be able to generate geometries for a large design space, so it would be good to try to generate a geometry even for edge cases of parameter choices.
• Principle of least surprise: How likely is it, that a user is surprised by TiGLs behavior?

So specific to this case: It would be nice if TiGL wouldn't be too strict so that it crashes or errors less and thus be more robust. But what should happen with negative values for the half-axis? Some users might expect them to be clamped to [0, 1], others might expect that TiGL uses the absolute value. So now we might surprise some users. Then the best we can do is to be explicit about what happens and your warning is pretty explicit.

[MarAlder]

Thanks for your feedback, also @AntonReiswich and @sdeinert via mail. I think I'll try to avoid the implicit assumptions and handle meaningless parameters with CTiglError. Especially in automated design space exploration, users might miss some warnings. The TiGL viewer will not crash and the Python wrapper will throw a clear exception message. Somehow I feel better about this. But still open for discussion.

Another point: Yesterday we discussed that some edge cases might be difficult with the idea of implementing it as a fuselage child. The tanks should also be placed inside and outside the wings, pylons and nacelles. So we decided that it would be better to pull fuelTanks out of the fuselage (keeping only the fuselage integral tanks as implemented in CPACS 3.4 and earlier) and reference them via parentUID. I guess no one really started using the schema, so I'll bring an update with CPACS 3.5.1 after finishing the TiGL implementation (in case we discuss further changes). @MarkusZimmerDLR, @sfreund-DLR @dlr-bt @dlr-ae