Include new deck definition

[ChristianHesse]

A replacement definition for the aircraft cabin or deck is proposed according to the attached mindmap. The new definition includes changes to make it consistent to the definition of the primary structure by referencing the fuselage cutouts. In addition, a basic description for the secondary structures (lining, hatracks and ceiling panels) in the form of the bounding box as well as a reference to a genericGeometryComponent is included.
The major changes and the rationale behind the new definition are discussed in detail in https://elib.dlr.de/135956/.

Edit: The uploaded mindmap has been changed to include the suggestion below by @jnwalther.

DeckDefinition_InDiCaD_v1.zip

[jnwalther]

We have discovered some abiguity in the description of the bounding boxes, as fallback if no geometry components are provided. It needs to be clarified which point within the box is used as reference for subsequent positioning. Therefore we propose to add an optional local reference coordinate in [0, 1] space, which defaults to 0.5 (COG of the box). To clarify affiliation, length/width/height of the box should also be renamed to dX/dY/dZ. This results in a structure like this:

<boundingBox>
  <dX>1.0</dX>
  <dY>2.0</dY>
  <dZ>3.0</dZ>
  <boundingBoxOrigin>
    <referenceXLocal>0.5</referenceXLocal>
    <referenceYLocal>0.5</referenceYLocal>
    <referenceZLocal>0.0</referenceZLocal>
  </boundingBoxOrigin>
</boundingBox> 

@ChristianHesse: I suggest we add this in an updated version of the above document.

[ChristianHesse]

Please find attached a schema definition (*.xsd) proposal for the revised deck definition.
newDeckSchema.zip

@marcengelmann & @MarAlder: We´re very happy about feedback and thoughts from your end.

[MarAlder]

First impression: very nice!! It follows well our concept of pre-defining library elements and linking it in the actual aircraft instance. It follows all naming conventions. I will give you more detailed feedback soon and then initiate step 2 of our development process, i.e. informing the entire community and getting feedback from stakeholders. But as the proposal already looks quite advanced I also already scheduled it for CPACS 3.4.

[marcengelmann]

I really like the new structure of the deck definition. As a regular user of the current style I think this will be a big step forward.
The challenge here is to satisfy both a top down perspective where the mechanical structure of the fuselage an cabin can be neglected (e.g. when using it for boarding simulations) as well as a detailed structural perspective.

From what I can tell now, this looks promising for both use cases.

I will definitely look into it in more detail in the coming days and give you proper feedback. But thank you already for the efforts you put into this @ChristianHesse and @jnwalther.

[marcengelmann]

After having attended the meeting there are a few things I discovered which I wanted to discuss:

• Galley/Lavatory Split
  We at Bauhaus Luftfahrt look at unconventional cabin layouts that can include a bar, beds, staircases, tables etc. Currently we include these with a custom literal at the floorElement type. With the new split, there is unfortunately no generic new element type possible.

• cabGeometry layers
  Just for clarification, in your presentation there were y-z shapes stacked along the x axis which is a change to the current implementation.

• Rotation of cabin elements
  You mentioned a translation option for cabin elements, but does this also include rotation of objects? E.g. if I wanted to create a seat group located around a table or a rotation of seats towards the aisle.

Thanks again for the very interesting stakeholder meeting!

[jnwalther]

Thanks @marcengelmann for your comments! I will go through them one by one:

• Galley/Lavatory Split
  After discussing with @ChristianHesse we have decided to re-introduce some kind of generic deck geometry type, which would be a bare-bones version of the deckElement types introduced during the stakeholder meeting (i.e. no metadata like numberOfSeats/numberOfTrolleys/... will be allowed).

• cabGeometry layers
  Sorry, I guess our slides were less than perfectly clear on this. Our implementation does in fact retain the definition as it was previously. The z entry in each contour node is a single value that corresponds to an entry in the old vector z. The y entry is a vector that corresponds to the respective yZi. The x entry is also a vector of the same length as all vectors y and constitutes the sample points for all contour entries, which is why it is located outside the contour list. I hope this makes more sense, somehow.

• Rotation of cabin elements
  All cabin objects have a transformation node, which comprises translation, rotation and scaling. For floor-based elements, this is a 2D transformation (translate on xy-plane, rotate around z-axis), which should serve your purpose just fine.

Does this answer your questions?

[MarAlder]

I implemented your proposal in the decks branch. Please have a look at the following points:

• Structural mounts are implemented as deckStructuralMountType

• Some minor node renaming; see documentation

• I extended the documentation. Please review carefully! I would like to make the documentation more user-friendly in the long run.

• Base type for deck (library) elements: As all deck elements have the same base nodes (description and geometry) it would be useful to apply a common base type and extend it, if necessary (e.g., for galleyElement and seatElement). The disadvantage: the nodes must be aranged as a prescribed sequence (which is feasable for the small number of nodes, I would say).
  

• I introduced a deckComponent2DBaseType (with 2D transformation) and deckComponentBaseType (with 3D transformation) which are used for the instantited decks in vehicles/aircraft/model/fuselage/decks/deck. Thus, the schema is kept lean and future extensions can be made with higher consistency and less error-proneness. I hope also object orientated tool implementations will benefit from this.
  

• (refers to Introduce a library node for external geometry #717 (comment)) Even if we also introduce a genericGeometryComponentsType in the library level (i.e., under cpacs/vehicles) it might be more useful for this case to introduce and directly employ a deckElementGeometryType, which is quite similar to the existing one but without parentUID, name and description. Since under "deckElements" the respective elements are defined only once, we should avoid an additional definition under cpacs/vehicles/genericGeometryComponents or something like this. See for example:
  

• The new doubleVectorBaseType is employed for cabinGeometryType, cabinGeometryContourType, cabinSpaceType and cabinAisleType.

• Galley/Lavatory Split: What is your proposal on this, @jnwalther, @ChristianHesse ?

• cabGeometry layers: Do we need to improve the documentation here?

• How do we model blended wing bodies? Is it useful to also add the deckType under the wing element?

[jnwalther]

Thanks @MarAlder for this grand piece of work. Overall I'm very happy with it. I checked all the boxes, where I don't feel we need to discuss much further (although I will go through the documentation once more in detail).

As for the unmarked ones:

• We considered the inheritance-based approach you propose, and we chose to not go through with it for the reasons you mention (fixed order), and also, because it is not done in this way in most other types in CPACS, as far as we saw. However, if you feel this is something we should do more in CPACS (which I can definitely warm up to), we can definitely do it in this way, too. Your call.
• I'm not sure I totally understand, what you mean by Galley/Lavatory split. I suppose you mean a monument, which contains both. This could be done by placing both halves as separate floorElements, or by placing one genericFloorElement (we want to reintroduce this type after discussing with @marcengelmann).
• The documentation in cab[in]Geometry definitely needs an update, as I found out that it is still quite easily misunderstood. I can prepare a proposal soon.
• For me BWB is not really a pressing issue, since (to my knowledge), so far noone has even attempted to describe a passenger cell on a structural level. Therefore, I feel like we can leave it out for the time being. Maybe we can take a closer look if someone proposes a project for it.

[ChristianHesse]

Thank you @MarAlder for your work on this. I would just like to add one little point. In the stakeholder meeting we have discussed the possibility to add mass descriptions for the cabin parts as the analysis/massBreakdown element should not be used for this. I would therefore suggest adding an optional massDescription element of genericMassType to each part described under deckElements. That way, the local center of gravity, mass and inertia can be described.

Also, the element structuralElements/seatModule can be deprecated as agreed in the stakeholder meeting.

[marcengelmann]

I also think that this looks quite nice! Thank you very much to you all.

Regarding the galley/lavatory split issue:

By this I did not mean some sort of mixed object with both a galley and a lavatory in one, but the newly introduced split in the CPACS definition from a generic floor element type to a galley and lavatory element type only. This lack of a generic floor element in the new deck schema prevents "unconventional" deck objects such as staircases, tables, bars, beds etc.

[MarAlder]

We considered the inheritance-based approach you propose, and we chose to not go through with it for the reasons you mention (fixed order), and also, because it is not done in this way in most other types in CPACS, as far as we saw. However, if you feel this is something we should do more in CPACS (which I can definitely warm up to), we can definitely do it in this way, too. Your call.

Hmm, I'm afraid it's always too much of a tradeoff between clean schema and implementation/usage effort to set a solution in stone for the one and only CPACS development guidline. Recent examples where we used inheritance are, for example, the new kinks (#630) or the new landingGear (strutType) definition (maybe also interesting #476).

For your deck definition I propose the following solution: most deck elements use exactly the same child elements. These should use the same data type (deckElementBaseType). The two deck elements that differ from this, galleyElementType and seatElementType, get a dedicated type that is manually copied and extended from deckElementBaseType. Thus we can use the xsd:all element and have a reasonably clean schema.

I'm not sure I totally understand, what you mean by Galley/Lavatory split.

Well, you said in #674 (comment) that you decided to re-introduce some kind of generic deck geometry type, which would be a bare-bones version of the deckElement types introduced during the stakeholder meeting (i.e. no metadata like numberOfSeats/numberOfTrolleys/... will be allowed). I think this generic element is what @marcengelmann would like to use to model taverns in the sky (which I strongly support 🍻).

The documentation in cab[in]Geometry definitely needs an update, as I found out that it is still quite easily misunderstood. I can prepare a proposal soon.

Nice!

For me BWB is not really a pressing issue, since (to my knowledge), so far noone has even attempted to describe a passenger cell on a structural level. Therefore, I feel like we can leave it out for the time being. Maybe we can take a closer look if someone proposes a project for it.

Fine for me. It was just a question from the audience when I presented the last CPACS paper at the conference.

In the stakeholder meeting we have discussed the possibility to add mass descriptions for the cabin parts as the analysis/massBreakdown element should not be used for this. I would therefore suggest adding an optional massDescription element of genericMassType to each part described under deckElements. That way, the local center of gravity, mass and inertia can be described.

We can do that. But maybe we should introduce a reduced individual type that does not contain the elements name and parentUID? Also orientation would be superfluous here, if the whole element is still transformed when linking in the actual aircraft/model, right? What happens with the scaling under aircraft/model? Can the moments of inertia simply be scaled up/down?

A little note to the redundancy in the analysis node: Currently, the massBreakdown does not link any elements under aircraft/model (I sometimes call this component level, see point 2 in the main documentation). Therefore, tools need to derive this information and update the massBreakdown when the component level changes. Sounds a bit stupid, however we follow this approach (i.e., analysis results do not scale with component level definitions) deliberately , as the data format itself should not contain modeling capabilities.

Also, the element structuralElements/seatModule can be deprecated as agreed in the stakeholder meeting.

Right. Since this is a breaking change anyway, should we remove this element?

[MarAlder]

Ok, final (I hope) changes are implemented:

Generic deck elements:

Deck element mass:

Cabin geometry documentation:

Reference to floor structure:

[jnwalther]

Thanks a lot for your work @MarAlder and @ChristianHesse! Looks really nice.

The only concern I have is whether we should really discard the orientation in the mass definition. The way I see it, it is meant to introduce a way to decouple the coordinate system in which the inertia tensor is defined, from the superordinate system in which the mass is defined. This might be useful if you want to provide the principal inertias, but the principal axes are not aligned with the coordinate system. (Btw, the documentation for orientation is a bit ambiguous. I'm assuming x, y and z are Euler angles analogous to rotation nodes).

Of course this is rather a convenience feature, since the tensor can still be expressed correctly by providing the off-diagonal entries, so it shouldn't hold back the release. Additionally, I'm really not too deep into this topic, but maybe the colleagues from the structural departments who will be using the masses can comment on this.

[MarAlder]

Hmm, you're right, the orientation node could have been used to define principal axes 🤔. Surprisingly, the documentation of the genericMassType is not very clear at this point...

Any expert opinions on this?: @DLR-BT, @sfreund-DLR, @sdeinert, @rmaierl

[MarAlder]

@jnwalther, @ChristianHesse, this issue can be closed, right?