Profile Based Structural Element - standard Profile Type extension

[rmaierl]

We would like to extend the number of standard profile definitions for the Profile Based Structural Element. to increase the flexibility of structural model generation.

Profile types to add:

• I
• T1
• T2
• C1
• TUBE2

Three sketches for I, T1 and T2 are attached to this issue.
The sketch of C1 is similar to the one of C.
The sketch of TUBE2 is similar to the one of TUBE.

Could you please check the attached profile sketches and add them to the documentation.

[MarAlder]

Thank you for the proposal. We can of course add more types. I still have some questions:

• T1 and T2 are 90° and 180° rotations, respectively?
• How about naming it a bit more intuitive?
• Did I interpret C1 (C90) correctly?
• TUBE2 = 90° rotation of TUBE?

The resulting documentation could look like below:

[MarAlder]

Attention: The pictures above do not represent the latest status of the proposal. Please see the documentation below.

Status

I commited a first implementation of this proposal with ed350bf:

• XSD Diagram
• Updated Documentation

We observed that the schema did not allow to specify a length of the standard profile sheets. Furthermore sheetUID can not referenc one of the corresponding identifiers in the figure. Thus, I added an alternative choice to sheetUID: standardProfileSheetID and length. This way, the sheetProperties are no longer pure material properties and the data provider needs to take care that the correct choice is taken with respect to the choice between a generic element and standard profile element. But the alternative would be to restructure the whole node.

Next steps

• Community feedback (e.g., @sfreund-DLR, @DLR-BT, @jnwalther)
• Add example file to example folder

[jnwalther]

I would like to point out, that most of the above profiles can also be described using the classical point/sheet definition in CPACS (Tube and Rod being the exception). Therefore, while I see the practical appeal for the engineer, we need to be aware, that we are creating a redundancy similar to the length/sweep/dihedral vs. transformation definition for placement of geometrical profiles, which has caused debate in the past.

As for the presence of rotated profiles (e.g. T90 and T180): Is there a specific necessity for this? Typically, profiles can be reoriented locally when they are being used e.g. using the alignment node for stringers, which is more intuitive to me if you think of profiles as semi-finished products.

[MarAlder]

With aba9260 I added an example including this alignment node for stringers. So given a T2 profile (open for discussion if one T-profile is sufficient) the stringer would be at 30deg of the fuselage circumference, pointing outside. Thus, I added a <rotationLocX>180</rotationLocX></alignment> so that it points inwards. For T I would instead use translationLocY with the length of S1, right 🤔?

Can someone check this example, please?

[sfreund-DLR]

I don't have a fixed opinion about the proposal. Using the new profiles, it is a little easier to create initial structuralProfiles. On the other hand, the new profiles can very easily created by using the transformation/rotation in the profileBasedStructuralElement as first choice. The alignment node is my second choice in this regard.

There used to be a standardProfileType "web" (I guess CPACS 2.3 for example), which could als be included again, if we introduce the new profiles above.

creating a redundancy similar to the length/sweep/dihedral vs. transformation definition for placement of geometrical profiles

I don't think it creates the same redundancy: the "length/sweep/dihedral vs. transformation" is appiled consecutively whereas the two profile variants are a mutual exclusive choice. Although I see the argument, that there are two versions of defining the geometry of such a profile, while the non-standardProfile version is the more universial one.

[MarAlder]

As for the presence of rotated profiles (e.g. T90 and T180): Is there a specific necessity for this? Typically, profiles can be reoriented locally when they are being used e.g. using the alignment node for stringers, which is more intuitive to me if you think of profiles as semi-finished products.

@jnwalther: I think its more about convenience. I agree with @sfreund-DLR that profile variants are a mutual exclusive choices. The example file should support this discussion. From XML point of view everything is clearly defined. So I'll leave this decision to the tool developers (i.e., only keeping T, removing T1 and T2 and using the stringer alignement instead) who must deal with the different approaches.

I would like to point out, that most of the above profiles can also be described using the classical point/sheet definition in CPACS (Tube and Rod being the exception).

Same argumentation as above.

To close this issue two actions remain:

• Verify the example file (wrt. my interpretation of the stringer modeling) (@rmaierl, @sdeinert, @jnwalther, @DLR-BT)
• Keep T1 and T2:
  • Airbus (@rmaierl): tends to yes
  • DLR-SL (@jnwalther): tends to no
  • DLR-FA (@sfreund-DLR): can live with both decisions
  • @DLR-BT: ?
  • DLR-AE: Do they have shares in this topic?

To remember the latest implementation:

[rmaierl]

Hi Marko,

sounds good, thank you.

I adapted the cpacs file a bit and generated an example mesh.
To make this work, a stringer position@fuselagesection would be mandatory, otherwise you will always have problems with the construction of the geometry.
profile_test_ads_xml.txt
profile_test_ads_bdf.txt

[MarAlder]

Thanks for your modified example.

To make this work, a stringer position@fuselagesection would be mandatory, otherwise you will always have problems with the construction of the geometry.

Yes, Sebastian already mentioned it last monday. We should open a separate issue for this.

[MarAlder]

No additional feedback on GitHub. Will be further communicated by mailing list, homepage, etc. and thus reopened in case of any further modifications.

[MarAlder]

@sdeinert @rmaierl: You mentioned at the stakeholder meeting that the example file needs a revision. Could you please update it accordingly? I re-opend the issue to not forget this task before the v3.3-RC release.