New function tiglGetCrossSectionArea

[rainman110]

We need a function that computes the cross section area between a component and a user defined plane.

This should work in line with the function tiglIntersectWithPlane.

Important: To be useful, also the intersection with the whole fused aircraft is necessary!!!

Hence, we might need to implement returning the shape of the fused aircraft via the aircraft uid.

[ErwinMoerland]

Background of the request for this functionality is the ability to apply Whitcomb's area rule.

The planes for calculating the cross-sectional area (or "intercepted area") are to be defined relative to the freestream direction and are inclined depending on the Mach Number. Due to this inclination, the cross-sectional area then also varies with the roll-angle theta (rotation around the freestream direction vector).

So following parameters for determining the plane orientation should be available:

1. the angleOfAttack and angleOfSideslip to determine the offset of the freestream direction vector to the body-fixed axes.
2. the relative position along the aircrafts' x-axis (from 0 to 1 from nose to tail)
3. the mu value (inclination of the plane relative to the freestream direction vector)
4. the theta value (rotation angle about the freestream direction vector)

Indeed, the cross-sectional area for the overall aircraft including all components (fuselage, wings, empennage, pods, ...) is required, so using the fused model seems the best way to go.

[rainman110]

@ErwinMoerland The current function to compute the intersection of a plane with the aircraft model is to simply give tigl the plane equation (e.g. point on plane and normal vector).

It would be up to the user to compute the correct plane.

Update: From my point of view, I'd really like to keep it this way, since it can be used in numerous ways.

[ErwinMoerland]

@rainman110 I fully agree with keeping the function generally applicable and not specifying it for area-ruling implementations only. The latter should be the task of a separate analysis routine using the intended tigl functionality.

When practically implementing the area rule in such an analysis routine, (other) tigl functionality can be used to calculate a discrete set of "points on the plane" to be considered (i.e.: discretizing the relative position along the aircraft's x-axis). Then - based on the flow conditions (angleOfAttack, angleOfSideslip, Mach number) and a chosen discretization of the theta value (from 0 to 2*pi()) - a set of corresponding normal vectors can be determined. For each {point, normal vector} combination then the tiglAreaOfIntersectionWithPlane (or similarly named) function is to be called.

[joergbrech]

Follow up question:

Is there a use case, where we need to calculate the cross section area for individual components rather than the whole configuration? If yes, can you provide an example?

If no, I suggest to just implement tiglGetCrossSectionArea for the whole configuration. We already have an implementation for fusing the whole aircraft. For individual components on the other hand it is not clear what the function should return: Should it return the cross section area of the component, fused with all its CPACS children? Or just a subset?

[ErwinMoerland]

@joergbrech: in the end, the target is to position components in such a way that a smooth cross-sectional buildup of the overall aircraft is achieved. So the implementation you propose would be more than welcome!

the figure on the F102A on this website might shed some light on the idea.

---

Having this cross-sectional distribution available, the next step would be to adjust the positioning of components (or the components themselves) in such a way, that a more smooth cross-sectional buildup is achieved. For this case, it will then be interesting to look at the cross-sectional area distribution of individual components. The question however arises whether TiGL should be able to provide this functionality, or if a tool should change the distribution and buildup of components and use TiGL to re-evaluate the cross-sectional buildup. I think this is of later concern. So let's stick to your proposal for a first implementation!