Improving smooth access to certain reinforcement areas in concrete sections

[DanielGMorenaFhecor]

In the GrossProperties attributes from the GenericSection class, the reinforcement area can be obtained. However, it would be beneficial to query these areas based on the position of the reinforcement (e.g., lower, upper) or by the diameter used.

Possible solutions could be to create a ReinforcementGroup or the use of tags.

Other approaches may also be considered.

[talledodiego]

In a Generic Section there is no such concept of upper or lower.
Right know we have the group_label property in the PointGeometry. We could use that for doing that.
We could add methods for doing such queries like select_by_diameter(18) or select_by_group(name) and return a list with the corresponding PointGeometry.

We also have the name attribute in PointGeometry that maybe can be used to the purpose so that we can group according to multiple criteria?

[DanielGMorenaFhecor]

Apologies if I wasn't clear earlier. When I mentioned lower or upper reinforcement, I was just using that as an example to illustrate how this utility might be applied.

That said, your suggestions for select_by_diameter(phi) or select_by_group(name) (and possibly even a select_by_tag(tag) if we want to support multiple tags) are solid approaches.

It's not urgent at the moment, but it’s an improvement idea that came to mind while we were working through the examples.

[MestreCarlos]

In a Generic Section there is no such concept of upper or lower. Right know we have the group_label property in the PointGeometry. We could use that for doing that. We could add methods for doing such queries like select_by_diameter(18) or select_by_group(name) and return a list with the corresponding PointGeometry.

We also have the name attribute in PointGeometry that maybe can be used to the purpose so that we can group according to multiple criteria?

I agree with this approach. However, I think it is necessary to organise the methods to be applied, and to prioritise them in the development. To put the most basic cases I think it is necessary:

1. Methods to create reinforcement bars like ‘add_reinforcement_line’ must include the input parameter ‘group_label’.

2. Methods to obtain group properties (Area, inertia) in ‘GenericSection’ class.

3. Methods to obtain results (maximum and minimum stresses) in ‘GenericSectionCalculator’ class.

Anything else? What do you think?

[talledodiego]

Sure, those are good suggestions.
I don't see immediately the usecase for asking for inertia of a group of point geometries. But we can add it for sure.
For obtaining stresses (maximum, minimum or actually the whole array) I don't think the right place is the GenericSectionCalculator class, but the results class. The results for instance could return stresses, strains etc. also in a nice way to permit user using its favorite plotting module like matplotlib or plottly or whatever. But the responsibility should be of the result class. Makes sense?

[MestreCarlos]

It is true that the inertia does not make sense, but the area does.

Regarding obtaining stress results, what you propose makes much more sense. Just to fully understand you, in the example of "calculate_bending_strength" which returns a @DataClass "UltimateBendingMomentResults", it would be necessary to implement a series of methods in this class so that, using the attributes of that class, the section: Generic_Section, and the group_label, it calculates the stresses or the strain in the reinforcements. Is that correct?

[talledodiego]

Yes, exactly but we should think carefully how to do it.
If we use fiber integration everything is intuitive: we can store stresses and strains in each fiber, so that user can obtain directly the data used for instance for create a matplotlib chart or whatever else.
With marin integration it is more tricky because we don't have such information.

Anyhow I think that the results dataclasses can become real classes adding relevant methods for extract more detailed results like stresses, strains, etc.

[mortenengen]

Thanks for a good discussion.

I have created a separate issue (#188) that deals with the missing kwarg group_label as highlighted by @MestreCarlos above.

I like the idea of implementing functions or methods for selecting reinforcement as described by @talledodiego and @DanielGMorenaFhecor above. Should these be separate utility functions, or methods on the CompoundGeometry class? I think perhaps the latter.