Material module naming & functionality

[robbievanleeuwen]

Moving the discussion from #12 on the material module to here.

[robbievanleeuwen]

@connorferster @Agent6-6-6 below are my thoughts on the material module ideas:

This discussion has made me realise that I haven't quite documented what is happening with the Steel material class very well. This is the way concreteproperties is currently operating:

• Regions that are assigned a Concrete material are meshed and stresses/properties are integrated exactly over the region.
• Regions that are assigned a Steel material are not meshed and are assumed to be circular. Stresses/properties are evaluated at the centre of the circle using the area of the circular geometry. This was done to speed up the calculations as I had it in my mind that all steel sections would be relatively small circles when compared to the concrete regions.

This means that if you were to model a composite section, e.g. an I-beam embedded in a concrete circle, the I-beam would just be treated as a lumped mass at its centroid.

Thinking about this further here is one possibility:

• Base Material class with attributes:
  • name
  • density
  • stress_strain_profile (service)
  • ultimate_stress_strain_profile
  • colour
  • meshed (boolean, whether or not the section is meshed or treated as a lumped circular mass, default True)
• Concrete(Material) class with further attributes:
  • alpha_squash
  • flexural_tensile_strength
• Steel(Material) class with ultimate_stress_strain_profile set to equal stress_strain_profile by default
• SteelBar(Steel) class with meshed set to False by default - this class would be used for all reinforcing bars.
• SteelStrand(Steel) class with meshed set to False by default and other parameters as required for prestressing (TBC).
• Other materials could follow a similar pattern e.g. Carbon(Material) and CarbonBar(Carbon) etc.

There are probably many ways to handle this but I think it would be good to decide on a strategy now as there will be some significant back-end changes in how the analysis works and results are displayed. I think this is an important discussion as it will open concreteproperties up to even more possibilities e.g. composite sections, carbon fibre reinforced sections etc.

Perhaps there could be advantages in harmonizing the two classes? (from #12)

I have thought about this previously and think it could be a good idea as technically when creating sectionproperties the materials we assign to them should be of a sectionproperties material type. The only thing holding me back was that materials in sectionproperties are frozen and I don't want this functionality for concreteproperties. I could probably autofill the non-relevant material properties that a concreteproperties user doesn't care about e.g. poisson's ratio. Would there be any implications for sectionproperties if the material class was unfrozen? Do you think the concreteproperties mateiral inheriting from the sectionproperties material would be too messy?

Open to other design ideas!

[connorferster]

Oooohhhh! I see that I misunderstood!

Base Material class with attributes:

name
density
stress_strain_profile (service)
ultimate_stress_strain_profile
colour
meshed (boolean, whether or not the section is meshed or treated as a lumped circular mass, default True)

Concrete(Material) class with further attributes:
alpha_squash
flexural_tensile_strength

Steel(Material) class with ultimate_stress_strain_profile set to equal stress_strain_profile by default
SteelBar(Steel) class with meshed set to False by default - this class would be used for all reinforcing bars.
SteelStrand(Steel) class with meshed set to False by default and other parameters as required for prestressing (TBC).

Wow, these materials are complicated! I think you have hit on a good model, though. You have treated the Concrete class as a special-case, which makes sense because it is special and because this is, after all, concreteproperties. Perhaps it could be even more special by being the only material which uses the ultimate_stress_strain_profile which would prevent you from having to do any thing funny in the __init__ or __post_init__ method for the Steel class (or the class of any other future material). This way all materials are assumed to use the same template except Concrete which would have those extra attributes.

Re: harmonizing Material:

I didn't realize that Material in sectionproperties was frozen! Generally in my code I tend to treat objects as though they are immutable unless they are made to be mutated (e.g. dict, list, matplotlib figure). Does the fact that it is frozen allow it to be hashable when creating MaterialGroups? Is there any where in concreteproperties where you need to mutate the material?

With poisson's ratio and the stress_strain_profile, I think it would be difficult to harmonize the two Material classes without having to make things weirdly "optional" but then also needing to be validated based on the context. I think that, if the only real connection between the data types in sectionproperties and concreteproperties are the geometries, that would be okay.

[Agent6-6-6]

I wonder for full transparency should stress_strain_profile be renamed to service_stress_strain_profile to match the similar ultimate naming nomenclature? Makes reading and understanding the code and input variables a little less idiot proof?

I think for the case of utilising an I-section section you'd treat cases like that quite separate to the finite point reinforcement, clearly in cases where the strain varies across a structural cross section and you might have some plasticity across parts of the section then it needs to be treated quite different.

I think for reinforcement assuming the area and force is all lumped at the centroid is more than sufficient, I can't think of any other analysis tool that treats it any different to this. Usually in concrete analysis the reinforcement strain are well past yield for the primary reinforcement so any variation in stress across a bar is not present.

One thing I've realised in attempting to implement the NZ code requirements is should you also have the yield strength (lower 5% characteristic) and the upper 95% characteristic strength as it is required for overstrength design in seismic (similar for concrete as well). For example in NZ we usually need to evaluate based on fy_overstrength = 1.25 to 1.35 x f_y, and concrete at f'c+15MPa with strength reduction factor of 1.0 for capacity design. Being able to store lower bound and upper bound material strengths would be required?

[robbievanleeuwen]

Thanks for the input 👍 I'll start working on these changes with the aim of incorporating the material module changes for a v0.3.0 release. I think I'll leave the sectionproperties Material alone and keep the two packages separate with regards to material objects.

Perhaps it could be even more special by being the only material which uses the ultimate_stress_strain_profile which would prevent you from having to do any thing funny in the init or post_init method for the Steel class (or the class of any other future material). This way all materials are assumed to use the same template except Concrete which would have those extra attributes.

I think I'm going to go with this approach. I think it is clear in the documentation how these profiles work and I think it would be confusing for most materials to have two separate profiles which are identical.

Being able to store lower bound and upper bound material strengths would be required?

I'm not convinced that adding this to the generic steel/bar/reinforcement/whatever I end up calling it class is the best approach as it will a mean this class will become quite messy as more codes are added and the more parameters are introduced. A lot of these parameters will remain unused for most codes and non-design code usage. Perhaps, where required, new material classes specific to design codes can be created? E.g. when you call NZS3101.create_concrete_material(), instead of returning a Concrete object it returns a ConcreteNZS object or similar...

P.S. I found out today I've got covid 😢 so this will either be a very productive or unproductive week, not sure which one yet 🤷

[connorferster]

@robbievanleeuwen So sorry to hear about your COVID. It's not fun. I found lots of bed rest necessary. Hoping it is not too rough on you.

@Agent6-6-6 We have similar seismic requirements in Canada. My thought is to manage this through multiple analyses, i.e. running a separate factored resistance, nominal resistance, and probable resistance, applying different factors and/or materials on the scripting side to my relevant values. The way Robbie has designed the various results objects seems to make this easier. Your thoughts?

[robbievanleeuwen]

I have created a new issue (#22) based off this discussion (and had some fun using mermaid!)

Again, let me know your thoughts!

[robbievanleeuwen]

@Agent6-6-6 @connorferster a preview of this branch is available at #28. It appears to be in working order, I just need to work on updating the documentation.

There's a nice little example here, also generated as a pdf for easy viewing: composite_section.pdf.

If you have some time to have a look over the naming/implementation I'd be open to suggestions as I always find naming the hardest part of programming 🤣

[robbievanleeuwen]

I've also simplified the implementation of the sectionproperties Geometry object in pre.py for use in concreteproperties. I get about a 20% speed increase in the analysis. Interestingly for a relatively simple geometry, 50% of the computation time is spent in splitting the section (shapely split + geometry object initialisation with rounding of coordinates), 25% of the time is spent on finite element stuff (summing stresses etc.), 10% on interpolating the stress from the stress-strain profile and less than 3% is actually meshing!

Thanks for the awesome implementation @connorferster, I felt like I was plagiarising a little bit when I was writing the CPGeom object!

[connorferster]

I love it! I spent some time this morning reading your implementation and the code is certainly familiar :) That's a big compliment!

Agreed, splitting the section can get expensive. I found that too when trying to implement a basic geometric solver for interaction diagrams. It seems that shapely operations in general can get expensive when operating on larger volumes. They are working on shapely v2.0 which, as I understand, will feature a dramatic speed improvement for bulk operations. The current shapely v1.8.2 is implementing changes in preparation for v2.0.

I read your PDF example this morning. It looks really great. This is really exciting stuff!

p.s. I think your names are good 👍

[Agent6-6-6]

The only comment I still really have is that stress_strain_profile be renamed to service_stress_strain_profile for consistency with ultimate_stress_strain_profile.

Otherwise the way the materials have been named and defined all make sense to me, great for extending to other engineered materials.