Description of parentUID usage unclear

[MarAlder]

The correct usage of the "parentUID" element should be clear from the respective descriptions in the documentation.

• [x] add description to XSD documentation
• [x] add description of usage to development guidelines

[MarAlder]

I checked the schema and found that only the massBreakdown is unclear on how to use the parentUID element.

Please carefully review the followig solution for the genericMassType which is used for the massDescription elements:

• Documentation with examples

I added the refType attribute to the location element. Thus, the reference coordinate system can be explicitly defined, but does not have to (corresponds to previous data sets; default=global). Additionaly the usage of the parentUID is better described.

pros:

• retains backward compatibility (as far as I belive this node is being used)
• combination of refType and parentUID similar to to geometric objects (e.g., wings and fuselages) --> consistency

cons:

• simultaneous definition of refType="absGlobal" and parentUID is possible, but maybe meaningless (?)

[MarAlder]

I added the guidelines for developers.

No clue how to adjust the table column width, though...

[rmaierl]

Hi Marco,

sorry for my late reply, but we are using the genericMassType parentUID in a different way. It was implmented in this way years ago (with Jonas) to attach a generic mass to the structure and to enrich the FE model generated by our in-house tool Descartes with connected mass points.

In this case it is possible to have none, one or more structural connections, therefore the node exists The nodes refer here to a wingStructuralMountUID defined in the wing componentSegment or to a fuselageStructuralMountUID defined in the fuselage/structure. The structural mounts define an intersection (point or line) where the mass will be connected. The example below should explain the the concept.

Payload mass description with connections

                  <mBulkCargo>
                    <massDescription uID="Payload">
                      <parentUIDs mirrorParents="false">
                        <parentUID>wingMount_stringer_cell</parentUID>
                        <parentUID>wingMount_spar_shell</parentUID>
                        <parentUID>wingMount_rib_shell</parentUID>
                      </parentUIDs>
                      <mass>0.8</mass>
                      <secondaryMass>0</secondaryMass>
                      <location uID="Payload_location1">
                        <x>6500</x>
                        <y>0</y>
                        <z>-750</z>
                      </location>
                      <orientation uID="Payload_orientation1">
                        <x>0</x>
                        <y>0</y>
                        <z>0</z>
                      </orientation>
                    </massDescription>
                  </mBulkCargo>

wingStructuralMount reference

                  <wingStructuralMount uID="wingMount_stringer_cell">
                    <blockedDOF>123</blockedDOF>
                    <takeOnlyEndPoints>false</takeOnlyEndPoints>
                    <fromStructureUID>model_Wing_CS1_upperShell_cell1</fromStructureUID>
                    <toStructureUID>upperWingStringer</toStructureUID>
                    <toStructureCounter>1</toStructureCounter>
                  </wingStructuralMount>

                  <wingStructuralMount uID="wingMount_spar_shell">
                    <blockedDOF>123</blockedDOF>
                    <takeOnlyEndPoints>true</takeOnlyEndPoints>
                    <fromStructureUID>Wing_CS1_sparSegment2</fromStructureUID>
                    <toStructureUID>Wing_CS1_upperShell</toStructureUID>
                  </wingStructuralMount>

                  <wingStructuralMount uID="wingMount_rib_shell">
                    <blockedDOF>123</blockedDOF>
                    <takeOnlyEndPoints>false</takeOnlyEndPoints>
                    <fromStructureUID>Wing_CS1_lowerShell</fromStructureUID>
                    <toStructureUID>Wing_CS1_ribsDefinition1</toStructureUID>
                    <toStructureCounter>1</toStructureCounter>
                  </wingStructuralMount>

I'm also not very happy with this solution and I am open for a change to overcame any misunderstandings. e.g.

 [0-1]<structuralInterfaces>
        [1-*] <structuralInterface>"structuralMountUID"</structuralInterface>
</structuralInterfaces>

[MarAlder]

Update: consistent parentUID concept in massBreakdown and in general

I have slightly modified the description of the parentUID concept in the massBreakdown to be consistent with the use of parentUID for the geometric components. This way, previous data-sets that did not use the optional parentUID element should still be valid and we achieve some consistency in the use of the parentUID node throughout CPACS.

massBreakdown: link

parentUID in main documentation: link (scroll down to Sec. 3.2)

Structural mounts

@rmaierl: Thanks Reinhold, I was not aware of this solution. I'll contact you for the implementation of your proposal. We are also having the need to enrich the massBreakdown with material information for LCA. Maybe we can align these things. I hope the description of the parentUID as proposed above is also o.k. for you?