Provide more versatile fuselage cutout profile definition

[jnwalther]

The current definition for structural fuselage cutouts as provided by the fuselageCutOutsType only supports rounded rectangle cutout profiles. However, some cases, such as cockpit windows or bulk storage doors, require a more fine grained modeling approach using rounded polygons, as illustrated by the following figures:

As a result, we have identified a need to modify the existing cutout definition. In order to achieve a more unified description approach in CPACS we suggest leveraging the existing profileGeometryType which is also being used for fuselage and wing cross-sections, and which already provides the capability to describe a rounded rectangle profile, but no rounded polygon type, which would need to be included.

To implement this in CPACS the following steps must therefore be taken:

• [ ] Add node cutOutProfiles of type profileGeometry[2D?]Type to profilesType

• [ ] Update fuselageCutOutType to include:

  • A reference to a cutOutProfileUID
  • A transformation[2D] to scale the profile from [-1,1] to the desired size.

• [ ] Add choice polygon to profileGeometry[2D]Type analogous to pointList, which also provides an optional corner radius (global or per corner).

Pending any objections, in particular from @joergbrech, @rainman110, @DLR-BT, @ChristianHesse and @rmaierl (did I miss anyone?), I would be willing to put forward a proposal for an update to the schema to integrate these changes.

[joergbrech]

@AntonReiswich, just wanted to tag you here as well.

[jnwalther]

I also just realized there may or may not be some relationship to #768. We can at least consider it.

[rmaierl]

To realize cutouts in the fuselage, cargo doors were implemented in Descartes. (I think we reintegrated this functionality also to TiGL) They remove an area bordered by two frames and two stringers. Fuselage skin segments are also implemented which are based on the same definition. But the give an additional structural property to the patches instead of removing it.

The fuselage cut outs looks very promising and this should replace the doors and skin segment definitions.

Anyway, a reinforcement element at the cutout border would be required from structural point of view.

According to your example, the fuselage skin does not just end. There will be a window- or door frame. So I would suggest to extend the fuselageCutOut type definition by an optional "borderFrameElementUID" element which refers via UID to a profile based structural element, which could be modeled as a BAR or BEAM in a structural model.

[jnwalther]

I think there might be some relation to #718 here. I guess that you are referring to the definitions from .../fuselage/structure/cargoDoor and .../fuselage/structure/deckDoor (i.e. doorAssemblyPositionType), correct?

To be honest, we have agreed internally to move forward with the fuselageCutOutType as the base truth a while ago, and I guess the matter of the non-rectangular (or at least four-sided) cutouts pretty much rules out a definition based on frames and stringers. That said, I appreciate the sentiment, that there should be some kind of relationship between the primary structural layout and the doors. If anyone has a smart idea how to include this in the approach above, it would be very welcome.

As far as I remember, the colleagues at @DLR-BT used to model door frames, so maybe there are some relicts of that to be found in CPACS. Subject to this, I think adding the borderFrameElementUID is a great idea. Maybe we can adapt the name to clarify wheter we mean the border on the fuselage or on the door side, but this is minor.

Finally, I would argue that we should not get rid of the skin segment definitions just yet, since those are the canonical way in CPACS to assign properties to the fuselage skin, as far as I know.

[jnwalther]

For what it's worth, the BT solution is described by Schwinn et al. and hasn't been used for a while (I think). Since we use the cutouts to model both doors and windows, there is no obvious one-size-fits-all solution. Therefore, I'm inclined to add an option for both a borderFrameElementUID to describe a possible reinforcement of the frame (e.g. cockpit window) and some kind of sheetElementUID or doorElementUID to describe the properties of the inner part of the cutout.

[MarAlder]

Thank you @jnwalther for you initiative on enhancing the doors/cutOut definition. I hope we can resolve the situation you already described in #718.

The following figure from Schmidt et al. helps (at least me) to understand the complex topic:

It looks like there are no objections to proceed with your proposal.

Just some first thoughts without diving deeper into this topic: For this issue we should work out a sustainable solution and not shy away from breaking changes in the schema, which will become necessary anyway. The term cutOuts/element is too vague for me and does not reflect the complexity that at least passenger doors entail. Maybe we can come up with a basic cutOut type and assign it to more explicit element names, such as:

<cutOuts>
    <passengerDoors>
    <windows> (necessary to define sets?)
    <maintenanceHatches> (adopting for wings ?)
    <cargoDoors>
    <landingGearDoors> (? just throwing ideas into the room...)
    ...
</cutOuts>

The basic type could then be individually extended, for example to include emergency systems to passenger doors or to account for the door reinforcements (e.g., not required for windows).

It might also be good to avoid detailed descriptions of structural elements in different places. An idea could be to first define the fuselage/cutOuts with its positionings, e.g. via the polygons you suggested, and then defining the reinforcement structure by replacing fuselage/structure/paxDoors and fuselage/structure/cargoDoors by fuselage/structure/doorReinforcements or similar. These could reference the fuselage/cutOuts and you would then have the ability to position appropriate stringers and frames relative to the door under. Just an idea.

Looking forward to first schema proposals :-)

[jnwalther]

Here is a first schema proposal:

fuselageCutOuts node:

Profiles node:

The only thing I'm unclear about is whether to use a 3D or 2D profile. In this example I used 3D, but maybe it should be 2D to reduce room for error. In any case it makes sense to harmonize the 2D and 3D profiles, which, however, merits a separate discussion, @MarAlder.

[jnwalther]

Sorry, @MarAlder I somehow missed your comment... I'm aware of the figure you sent and truth be told, maybe matching stringer and frame positions is rather a job for a KBE tool, than for a data container format. Based on that, I kind of stand by my suggestion above. An alternative idea I have could be to introduce some more types of structural elements, similar to bulkheadElements, which we could use to store more structural details, which we could assign as surface/frameStructuralElementUID.

[ChristianHesse]

I would like to add, that there are analyses, where the window frames can not be represented by a bar or beam element. For vibroacoustic model generation we currently model the window frames by using seperate sheet elements. These are created using an additional oversampling of the cutout shape, which is defined by an offset from the width and height of the cutout:

I would propose to add a choice element, to define the reinforcing frame either with a reference to a profileBasedStructuralElement or with a reference to a sheetBasedStructuralElement (windowFrameSheetElementUID) and an additional windowFrameWidthOffset + windowFrameHeightOffset. This of course necessitates an additional surfaceStructuralElementUID to describe the inner part of the window cutout, as @jnwalther pointed out and already included in his schema proposal.