Modify primitive geometry definition for systems and decks

[MarAlder]

In the course of implementing the new system definition in TiGL, I would like to suggest a few adjustments to the elementGeometryType, which is currently used for systemElements and deckElements (and planned for payloadElements):

I think that the primitive geometries should be kept as simple as possible, but we also have the philosophy to allow highly detailed geometries. So, some thoughts:

• I would like to replace the current parallelepiped with polyeder, which basically enable cuboids and can be extended towards either parallelepipeds or wedges via a choice element (because pyramids and prisms cannot be modeled precisely with our fuselage lofting algorithm). The coordinate origin should be moved to the lower left corner to make the wedges easier to define (will be documented again with illustrations)

  • 

• frustum: I consistently want to move the coordinate origin to the center point of the lower surface

• sphere I would like to replace this with ellipsoid, as these are often used in practice

• I don't really want to use scaling - the absolute values should be specified directly via the dimensioning parameters

• I would like to replace genericGeometryComponent with external to avoid confusion with generic CPACS parametrization (see next point)

• I would also like to introduce generic, which may use the fuselage approach and is only made up of sections and segments. This allows the parametric profiles, including superellipses, to be used to define any geometry. Important here: I really only want to enable fuselage-like geometries here, so I don't want to adopt any structures or other elements

• boundingBox: I don't necessarily want to delete this, but we should discuss the added value compared to the other primitive solids. It could be an idea to add an attribute bounding="True" or similar to the geometry element if necessary to distinguish between a bounding geometry and physical geometry.

I suspect that occasionally there is a requirement to combine several bodies with each other. Example of use: missiles for military configurations with fins. Therefore, the following considerations:

• I think the default behavior should be to choose only one primitive geometry. I would therefore like to avoid starting to predefine such things like geometry libraries at this level, which would then have to be linked together in assemblies via uIDs, or similar complex approaches...
• Should it really be necessary to combine several bodies, there should be an explicit sub-node that allows combinations of primitive geometry and SE3 transformation (translation and rotation). I want to avoid uID links at this level, so everything relates to the origin of the initial geometry (which is clearly defined via documentation and TiGL implementation)

What do you think, @joergbrech, @CLiersch (thanks for our first brainstorming), Christian H., @sdeinert, @rmaierl, Erwin M., others (feel free to forward)

[jnwalther]

Thanks for the proposal @MarAlder! I think it's a really good initiative. If I may, I would like to give a couple remarks:

• Rather than using polyhedron I would suggest to stick with something like cuboid (as you said yourself 😄). Technically, a polyhedron could be a soccerball (or a bunny), but a pyramid is still a cuboid with collapsed edges, so it's still sufficiently general for what you propose.
• I'm struggling with the parallelepiped description in the CPACS docs. Maybe a sketch would be helpful, since the references to the x/y/z coordinates (which are supposed to be basis for the lengths a, b, c) become kinda hard to follow when you have combinations nonzero alpha, beta and gamma.
• For the OCCT implementation of the parallelepiped, placing the origin at the corner of the cuboid would be quite useful since it would make it very easy to use the available box primitive combined with a GTransform and be done. Additionally it's consistent with the way we did it in boundingBox.
• I'm fine with renaming the genericGeometryComponent to external. But I would propose to not use generic for something different to avoid confusion and refer to fuselage-type shapes using something along the lines of multiSectionShape instead (i.e. something you could generate using the ThruSections function).
• I'm supporting the idea of using a bounding attribute to get rid of the boundingBox in favour of the polyhedron/cuboid definition as long as the geometric definitions do not diverge too much (s. origin of cuboids).

[MarAlder]

@jnwalther, thanks for your valuable feedback!

I agree with your comments and will consider it in a revision of my proposal.

Only one thought: I'm fully aware that a polyhedron can be basically any shape with sharp corners and straight edges and I had similar thoughts on the naming. But as far as I understand it, the definition of a cuboid is that the side faces are rectangles. A pyramid or prism is therefore by definition not a cuboid with collapsed edges. Therefore, our idea was to use the possibility of mapping cuboids, parallelepipeds or wedges (I don't think this is an official term either) as subset of polyhedra and at least make it clear that we have an angular body here, in the knowledge that a polyhedron can also be much more. Unfortunately, I have not yet come up with a more specific generic term.

Or we say, hey, this is a basically cuboid, and we deform it a little with the additional parameters, knowing that the element name is then no longer entirely accurate.

Btw: Thanks for indirectly pointing out that I was still using the German term for polyhedron :)

Edit: Maybe prism, and in the case of a pyramid treating the opposite face infinitely small? 🤔 Although the parallel faces of a prism can of course have less or more than four edges again..

[jnwalther]

Sorry, I didn't put too much research into the proper terminology. The Wikipedia article differentiates between a rectangular and a general cuboid. As far as I understand, the latter includes any convex hexahedron, which should cover both wedges and parallelepipeds, along with some other stuff. For the pyramid/prism special case, it might be a matter of interpretation, whether we allow the zero-area face or not. But since it's there based on the OCCT implementation using wedges, I wouldn't say it's completely wrong.

Another thing occurred to me concerning usability, though, since, if someone wanted to create a pyramid, it might not be the most obvious idea to go for a cuboid. So, I was thinking if it might not be an option to keep wedge and parallelepiped separate. That would eliminate the naming trouble and separate the two different parametric approaches. Of course it would mean there are multiple ways to define the same box, but strictly speaking this is already case, since you could also use a multi-section shape to do it (using two rectangular standard profiles). But I'm sure you have already considered this.

[MarAlder]

Oh nice, I wasn't aware that the term cuboid could be used so generally. In fact, most shapes we are talking about are covered by it. From my perspective, the pyramid - whose second parallel surface is then infinitely small - would also be ok if we treat it as general cuboid then (I would of course use the OCCT wedge implementation and treat as 0).

One argument that actually spoke against the explicit use of both parallelepiped and wedge for me is (as you said) that there would be two very similar nodes for the definition of rectangular cuboids. In practice - at least for the system definitions - I assume that rectangular cuboids are needed 99% of the time, while parallelepipeds or pyramids will probably be very rare (see our current study). This is why I want to avoid having half of them in CPACS using parallelepipeds and the other half using wedges. And of course, one can also define cuboids using the segment approach, but this is less likely to happen in practice.

So, I like the idea that most users need cuboids, we provide explicit cuboids via this proposal, and if users really need parallelepipeds or wedges, its mathematically also ok to call them cuboid. And the edge case where the second face collapses to zero... here we should perhaps stretch the definition a little in our favor 🤷‍♂️

[jnwalther]

OK, I see your point. In that case, I would agree that a single cuboid definition would be fine. 👍

[MarAlder]

Nice, then we'll have (plus boundingShape bool attribute for elementGeometryType):

[MarAlder]

I found some time starting with the TiGL implementation. During this, I'm still struggling with the idea of having the possibility to define a parallelepiped via alpha, beta, gamma. Some thoughts on three approaches:

Parallelepiped

The current documentation shows the definition of the angles. Coordinate system will move to the lower left edge and element names will change (see above).

General pro/cons for parallelepipeds:

• ➕ If we are currently implementing generic cuboids, why not considering it?
• ➕ Might be more intuitive than via multiSegmentShape for small angles
• ➖ Strong dependency between the valid range of angles (if gamma is small, then this limits the valid range for alpha. Else, we need to give the depth vector a z-component so that the lower surface is not in the x-y-plane anymore; I guess this additional degree of freedeom does not simplify things...)
• ➖ Prone to errors, as there is no OCC implementation available (implementation effort for correct exception handling in TiGL high)
• ➖ Redundancy: Parallelepipeds with rectangular lower surface can also be defined via the wedges approach (second choice of elements upperFaceXmin, etc.), squewed parallelepipeds (if needed) via super ellipses in multiSegmentShape
• ➖ Implementation effort vs. how much needed by practical applications (is there a need anyway?)
• ➖ Tricky to define, first quick shot for testing: Desmos3D

Defined via lengthX, depthY, heightZ`

This comes from a nice brainstorming with @CLiersch, following the idea, that the edges should be defined so that the depth and height of the lower face is defined, while the edge lengths adopt accordingly. The figure below shows a parallelepiped with lengthX=1, depthY=1, heightZ=1, alpha=beta=gamma=70deg:

• ➕ For small angles, this might be more reasonable for engineering purposes (space allocation)
• ➕ Naming convention is clear, as length in X is constant, depth is strictly defined in Y and height defined in Z
• ➖ With small angles, the edges grow quickly, reducing the intuitive engineering approach described in the first point

Defined via edge lengths

• ➕ Might be easier to understand, if edge length and angles are defined, even for small angles
• ➖ Naming convention difficult (lengthY, b, ...?)

No Parallelepiped

• ➕ This makes the CPACS implementation more convenient (no sequnce needed, if the upperFace parameters are optional)
• ➕ Reduce redundant approaches to model parallelepipeds via wedge or multiSegmentShape
• ➕ No individual TiGL implementation needed (no OCC method available)
• ➕ CPACS definition a bit more consistent (wedges defined via min/max parameters, while parallelepipeds via angles)
• ➖ What if needed in future?

With this in mind, I tend towards the last option of not adopting the parallelepipeds. If one really needs distorted parallelepipeds, one might find the multiSegmentShape more intuitive anyway. If needed, most parallelepipeds probably also have a rectangular base, and can be modeled using the wedge approach.

What do you think, @jnwalther, @joergbrech, @TimBurschyk, Thimo, @CLiersch, @sdeinert, @rmaierl?

[joergbrech]

My opinion on this is obviously biased towards code simplicity, I don't have the engineers perspective.

I believe that adding complexity such as a parallelepiped should be justified by a proper use case. If no one needs it, let's leave it for now.

[joergbrech]

That being said, here are two additional parametrizations that should be fairly simple to implement are the following:

A sheared cuboid

We could add an option to the cuboid for shearing along two axes. This can be implemented directly with a transformation matrix, see also https://en.wikipedia.org/wiki/Shear_mapping.

Three swept vectors

https://en.wikipedia.org/wiki/Parallelepiped#/media/File:Parallelepiped-bf.svg

We can define three vectors starting in the origin. The base is the first vector swept along the second and the parallelepiped is the base swept along the third vector. See also https://dev.opencascade.org/doc/refman/html/class_b_rep_prim_a_p_i___make_prism.html.

Optionally, we could restrict the definition: We define the x-vector just by a length along the x direction, the second vector must be defined in the xy-plane with positive components, the third vector in the yz-plane with positive components. Then we have just 5 double values for the definition and the lower corner always remains in the lower corner.

[MarAlder]

Feedback from @thimobielsky, expert in aircraft systems engineering at TU Hamburg:

In our opinion, the parallelepiped has no added value. I can't think of any system components off the top of my head that we could represent with it and I'm afraid that the effort and complexity, especially in the context of the preliminary design, could be increased.