Parametric Fuselage Profiles

[sdeinert]

Similar to the CST parametric definition of wing airfoils, it would be very useful to allow parametric fuselage profiles as an alternative to the existing point lists.
For this it would be possible to have a catalog of basic profile shapes to be supported at first, such as:

• Circle
• Ellipse (if circle with different scaling is not sufficient)
• Box/rectangle, with optional corner radius
• Super ellipse
• Two circles
• etc.

For one thing this would simplify creation of CPACS models; e.g. if you already know your fuselage shall have circular sections, you do not need to discretize a circle into a point list first. But also looking at the improved performance and robustness of CST wing airfoils in TiGL due to less complex spline geometries compared to point list airfoils, this seems like the logical step to also introduce something similar for fuselage profiles.
Additionally the parametrization of profiles would allow high fidelity optimization of fuselage shapes.

[CLiersch]

Thanks for bringing up this issue again. I think, it would be very useful to have a parametric definition for simple, typical fuselage shapes in CPACS. However, I would not place to many different types as a choice there. Thus, I would propose to introduce a generic super ellipse shape for fuselage profiles (consisting of separate definitions for upper side and lower side shape). In fact, this would cover most of the abovementioned cases, but is just one additional option to be handled.

[sdeinert]

I agree with you that the number of standard profiles should be kept small to avoid clutter. However, I would argue that, even though one can generate these shapes using a super ellipse, circle and square should be available separately so that they can be defined easily without having to provide a specific combination of parameters for the super ellipse.

My proposal would look like this in CPACS:

With the standard profiles defined as:

I don't know if radius is strictly necessary for the circle profile, as I would argue that these standard profiles should be normalized at least in width (best in both directions).

[rainman110]

I am also in favour to normalize all profiles to 1, so no radius would be required on case of the circle.

[rainman110]

There ratio with to hight should have the same name in the superellipse and in the rectangle.

Also, a circle is actually not required, since it is a special case of the super ellipse.

[sdeinert]

The reason for an extra circle definition is the simplicity. Yes, the super ellipse covers this but only for one specific set of parameters and, as the circle most likely would be the default profile for new components, I would like to circumvent the step of specifying 5 parameters just to get a circle with diameter 1.0.

heightRatio and widthToHeight have different meanings:

• HeightRatio affects how much height the lower half of the super ellipse covers and how much the upper half. The overall height and width stay at 1.0 regardless of its setting.
• widthToHeight changes the overall dimensions of the rectangle profile (either height or width, depending on what we agree on to be normalized).

[rainman110]

There is still the possibility to scale the profile afterwards using the CPACS transformation node. Therefore, widthToHeight is then not really required, right? Same argumentation as for the circle diameter/radius.

[MarAlder]

I guess m_lower and n_lower is what Wikipedia refers to as a and b?

• so called nil-able elements are possible as long as specified in XSD (see here)

• square (should be rectangle): to specify that the exponent must be infinite to approximate a rectangle from a super ellipse is informal from a data modeling point of view and should be avoided in CPACS. Setting the exponents to 1 and rotating by 45deg could technically be possible, but I admit that this is too cumbersome without a proper library function doing such transformations. So I propose to keep the rectangle element as choice.

• I know that my predecessors tried to avoid redundant definitions in CPACS if possible. I think that the data model must clearly show how the parameters are to be interpreted and, from a data modeling perspective, I am not necessarily against different approaches using choice elements. From the user's point of view, we must of course find a compromise between a not too complicated data generation (e.g. directly specifying a circle) and the effort to integrate CPACS in the tools (checking the different choice options in the tools). At this point, I suggest that we go without the circle for now and would ask the tool developers to check whether the query for Exponent=2 is acceptabile in the implementation. If it causes too many problems, we can discuss adding the circle element. But that might be better than deleting an element afterwards.

[sdeinert]

No, I would say a and b should both be 1.0 so that width and height of the ellipse profile are always 1 and can be scaled differently afterwards.
m_lower and n_lower are the exponents (n in wikipedia). Using different values (n and m) for both items in the sum allows more flexibility in shapes.

[MarAlder]

There is still the possibility to scale the profile afterwards using the CPACS transformation node. Therefore, widthToHeight is then not really required, right?

Could it be that we need the widthToHeight ratio for a clear definition of the edgeRadius in the square/rectangle element? Otherwise the rounded edges would be elliptical after transformation 🤔 But then again two superimposing ways of defining the ratio..

[MarAlder]

Ok, please have a look at this proposal and comment for further enhancements (compare with online-documentation):

square

I don't really like empty elements in CPACS. Although the Eclipse validator successfully valdiates the empty element, it should be invalid according to this explanation: xs:nillable (even with elementFormDefault="qualified"). Forcing the user to always add the xs:nil attribute also seems quite cumbersome to me.

Thus, I made the cornerRadius obligatory ranging from (including) 0.0 to (excluding) 0.5.

superellipse

My interpretation of the parameters is illustrated by this plot (pretty cool browser app, by the way..) and these remarks. Here, R is our lowerHeightFraction. Note that the exponents are restricted to values above 0 and lowerHeightFraction to values between 0 and 1. With the first restriction, also NaN is somehow not a valid entry anymore. But as noted in the documentation the user may use square instead.

Please also find the corresponding example file here.

(@DLR-BT, @sfreund-DLR, @CLiersch, @jnwalther, @rainman110, @sdeinert, ...)

[MarAlder]

Since the rounded corners would no longer be circular when subsequently scaled from a square to a rectangle is performed afterwards within the fuselage definition, the square was replaced by a rectangle. Thus, I included a heightToWidthRatio and the cornerRadius (@sdeinert, I hope it's ok to not use widthToHeightRatio because I assumd a constant width when deriving the equation..)

In principle the rounded edge could also be parameterized by a tangential ellipse. But maybe this is no longer relevant in practice. Below a screenshot of the current documentation. You can use the desmos plotter to play with the parameters.