Groups in SAF

[vaiguo]

Hello,

Grouping objects by similar attributes (sections, load values, purpose etc) is common and powerful option in FEM packages. Do you have plans to implement Groups in SAF?

Regards, Vaidas

[sonkaste17]

Hi @vguogis,

thank you for raising the topic. By the grouping of objects, do you mean creating something like a "design group"? For example, I will have all columns with the same cross-section and length assigned to one group defined in the SAF?

Regards, Štěpán

[vaiguo]

Hi Štěpán @sonkaste17,

Let's say design group, assembly, similar joints, RC beams with the same concrete class and so on. Fo rexample, grouping of trusses by axes: T1, T2, T3... That allows faster selection and preparation of reports and diagrams.
Format of grouping is quite simple - Group type (joint, member, plate, geometry...), Group name and list of elements.

Regards, Vaidas

[sonkaste17]

Hi Vaidas, @vguogis

I understand now. We did not intend to extend SAF this way, there was no requirement for doing this until now. Do you see the benefit of this kind of grouping in the time savings by the fact this grouping will be passed together with the analysis model?

Regards,
Štěpán

[vaiguo]

Hi Štěpán @sonkaste17,

I see huge benefit in grouping and I work in this way for a long time. Grouping is my primary option to manage complex structural models. It makes easy to set constants, sections, loadings or design parameters for a group instead of list of elements.

Update: here is a sample of upper chord selection by group in attachment.

Regards, Vaidas

[sonkaste17]

Hi Vaidas, @vguogis,

isn't this grouping quite similar to the "Layer" property that you can define for all analysis objects like StructuralCurveMember, StructuralSurfaceMember?

What kind of software are you using for modelling and/or for structural analysis?

Regards,
Štěpán

[vaiguo]

Hi Štěpán @sonkaste17,

To note, single object could belong to multiply groups. Let's say a chord element could belong for example to TRUSS, TRUSS-AXIS-1, CHORD, CHORD-1, S355J2, BUCKLING-LZ-6.0, BUCKLING-LY-3.0. And Geometry type of group could contain beams, plates and joints in itself if required.

I use STAAD.Pro but as I know the same approach of grouping is used on Robot, SAP2000, ETABS, SCAD and probably other FEM software.

Regards, Vaidas

[vaiguo]

Exactly. And it could be great to create an option to specify attributes by groups. For example, to create a group for support joints named as "FIXED-SUPPORT" and use this group name instead of joint list at StructuralPointSupport tab for a single row specification of this kind of support.

[dschuermans]

In theory, the Layer property could be used to achieve this goal.
It's perfectly feasible to provide eg a delimited string of all "groups" that a single object belongs to.

The upside: you can immediately tell to which group a single object belongs by looking at the SAF file
The downside: "removing" a group would mean going over the entire model, scanning for objects which use that group.

If you put this on a separate sheet like you are suggesting, then it's basically the other way around.
Its easy to manage your groups and which objects are part of a single group, but it'll be hard to tell to which group(s) a single object belongs.

In either case, it boils down to the application implementing SAF on how to deal with it.

From the SAF SDK perspective, putting it in a separate sheet poses some challenges, because we'd need to know to which type a name belongs, as we have unique names per type and not unique in the entire model.
So it's possible to have an object with the same name, but of different types.

From the top of my head, i'd go with dynamic columns then, with a set of 2 columns per type.

Name	Type 1	Entities 1	Type 2	Entities 2	Type 3	Entities 3	Id
G71	StructuralCurveMember	B1;B2;B3	StructuralSurfaceMember	S1;S2;S3	StructuralCurveMemberRib	B1;B2	af3be545-3b67-4873-bad7-1cd9391b88d1

[dschuermans]

Exactly. And it could be great to create an option to specify attributes by groups. For example, to create a group for support joints named as "FIXED-SUPPORT" and use this group name instead of joint list at StructuralPointSupport tab for a single row specification of this kind of support.

By this you mean instead of having 5 entries for example on the StructuralPointSupport sheet, all with the same contraint values etc but different names & ids, you'd have a single entry who's name refers the group, which holds the 5 names of those supports?

[vaiguo]

Yes. And to edit supports list it is easier to change list of joints at Group tab instead of add/remove rows at StructuralPointSupport tab which can contain Group row for dedicated support type only.

[sonkaste17]

I will prepare a short SAF example that we can discuss and others can easily follow.

@vguogis To groups, it is intended to have multiple object types in one group? Do you handle groups that way? It is possible the way Dirk mentioned above. For example, we can have "TOP-CORD" group. The group could consist of a set of "StructuralCurveMembers" (1D elements) and StructuralPointConnection (nodes) ... so I can imagine I can apply a StructruralPointAction (point load) and StructuralCurveAction (line load) to that group. Load then would be applied to all relevant members in the group.

[vaiguo]

Sometimes it is helpful to have different object types in one group. For example to filter ROOF geometry which consists of top chord elements, purlins and decking plates or surfaces. Or to set concrete class to columns and beams as members plus walls and slabs as plates.

[Heroog]

For that you could use the layer option. This works like layers in a CAD system. I can follow your request for groups of similar objecttypes to reduce the amount of input and for quick changes.

[vaiguo]

In addition to reduced amount of input data, grouping adds better readability.
If group named as "_COLUMN" consist of members B1 B2 B3, then specification of section like
_COLUMN TABLE ST HEA240 is clearer for user to follow in comparison to
B1 B2 B3 TABLE ST HEA240
Dependent on FEM software input format, of course.