search

DLR-SL / CPACS

CPACS - Common Parametric Aircraft Configuration Schema
http://dlr-sl.github.io/CPACS/
Apache License 2.0
80 stars 38 forks source link

Do we really need all these floor structure types? #492

Open jnwalther opened 7 years ago

jnwalther commented 7 years ago

Right now, we have the following floor definition elements in the CPACS fuselage structures branch:

I am wondering if we really need to distinguish between paxFloor and cargoFloor, because in the end, they describe the same thing. Furthermore, for an A380-like design with two pax floors, those would be mixed together in the pax...-branches and thus hard to distinguish just by looking at the file. Instead, couldn't we introduce a more tidy floor description like the following:

<floors>
  <floor, uID='descriptive_uid_like_upperPaxFloor'>
    <crossBeams/>
    <crossBeamStruts/>
    <longBeams/>
    <panels/>
  </floor>
</floors>

This would make for a nicer distinction between floors and at the same time eliminate the duplicity of data types. The same thing could also be done for doors.

rmaierl commented 7 years ago

Hi, I would like to add the pax/cargoDoors to this list.

Furthermore we are are missing a two-dimensional structural element in z-x plane (some kind of wall). Also I see no possibility to connect a long floor beam and a fuselage frame with a floor definition.

codingpoets commented 6 years ago

@kngbuzzo : I appreciate your suggestion. We should probably try and keep the definition as slim as possible. Is there a reason why we might need to make a difference between cargoCrossBeam and paxCrossBeam? Maybe we need to tell them apart in some code. Although in that case I would suggest an additional mapping via uids, telling which crossBeam is which. Are they to be handled differently during the design?

jnwalther commented 3 years ago

Given the recent advances in issue #674, I have decided to bring this issue back from the dead, as I think it would be great to connect a deck instance to a structural floor instance for various reasons.

Here is a suggestion for an updated floor structure definition schema: floorSchema.zip

floor_structure_crop

As illustrated by the figure, the new suggestion deviates from the inital one in that all structural floor elements are stored in flat lists. The floor entries provide a grouping via crossBeamUID lists. This is sufficient, since all other elements (i.e. struts, long beams and floor panels) refer back to crossbeams directly or indirectly, which determine their affiliation with a given floor. There is the issue that a longFloorBeam could span two floors, but this was possible before, too.

Overall, I believe this solution achieves what we need, while keeping disruptive changes at a minimum. @rmaierl, @MarAlder and @DLR-BT, what do you think?

As for the door issue mentioned by @rmaierl I think this is a sufficiently large mess to merit its own seperate issue...