Agree with your points above, James. My first thought was, like yours, to focus on the tasks structural engineers do most frequently - bending checks, shear checks, etc. But on second thought I think there's another aspect which is important - other tools in the industry. I think the priority should be on tasks that are done frequently which don't have good existing tools.
Flexural strength, for example, has a plethora of tools available. Shear capacity doesn't have nearly as much available. Or say, fatigue design of steel? Gunnstein has a fantastic library for doing rainflow analysis (https://github.com/Gunnstein/fatpack), but it would be great to see this put together with a codified method.
With respect to handling Design Code changes: I suspect this will be easy. I'm sure you're intimately familiar with how long it takes for Standards to undergo changes, and then when they do change, there's still errors! I can think of half a dozen off the top of my head in the Australian Bridge code which are still hanging on from 2017 😂. So I think the open-source community will be able to respond much, much faster.
Thanks Luke! Apologies for the slow response, I was unplugged over the holiday season.
Good points and I think we're on the same page.
One important distinction is that structuralcodes is not intended as an analysis package so all analysis should be outside of structuralcodes. Once you understand your demands or your design criteria - then you can use structuralcodes to check your members and ensure code compliance. There are no open-source projects that I know of that are aiming for this.
First of all, I would like to thank you for the StructuralCodes library. For me, the most laborious task when using Etabs/Sap2000 programs is the difficulty of obtaining section moment-curvature and section damage limits. In order to obtain the relevant values, it was necessary to resort to the Xtract section analysis program, which had to transfer the values to Excel and process them. Thanks to you, I will now be able to directly define plastic hinge and assign it to sections (with my phyton codes). But I have a few questions I would like to ask you.
1) Will a cross-sectional analysis result made with the StructuralCodes library be compared with a proven program such as xtract or with a previously verified calculation?
2) Will it be possible to define the behavior of confined and unconfined concrete separately?
3) I live in Turkey. I would like to define my concrete model myself, which I created by taking into account the wrapped concrete behavior defined in TBDY-2018 Code. Does the StructuralCodes library allow this? If not, will it provide it in the future? If it does, will the analysis time be short enough?
4) Can a separate function be defined to idealize the moment-curvature values ((0,0), (ideal curv_y, ideal M_y), (curv_ultimate, M_ultimate))
Hey James - to answer your some of short 'survey' questions:
1) I don't have the answer to this question right now as I'm new to collaborative library development!
2) Can treat it somewhat like a code committee (minus the politics) in that there are set targets for codebase updates and some level of 'peer review' after the actual updates to the codes/standards occur.
3) Would initially want "common" resistance checks to be covered (sectional, member), eliminating the need for in-house spreadsheets. Workflow wise would really depend on the portion of the building code or design standard we are looking to develop, could be simple (column design from axial loads derived using code combinations) to very complex (capacity design of LFRS elements) that would rely on some interfacing with a structural analysis package (whether open source or commercial) but the latter is perhaps beyond the scope of this library for now.
This is tricky, almost everyone in our field is already overworked and has zero additional time to allocate to maintaining an open-source project like this. I am not sure yet how this will work in practice. Some sort of streamlined code review process where pull requests only suggest one change at a time would make it much easier to adopt. This is an extremely important topic though so thanks for highlighting it.
3) - Agreed. Structuralcodes carries out the member checking process, after you've completed your analyses and understand your demands. This can be easily automated once the modules are set up.
Agree with your points above, James. My first thought was, like yours, to focus on the tasks structural engineers do most frequently - bending checks, shear checks, etc. But on second thought I think there's another aspect which is important - other tools in the industry. I think the priority should be on tasks that are done frequently which don't have good existing tools.
Flexural strength, for example, has a plethora of tools available. Shear capacity doesn't have nearly as much available. Or say, fatigue design of steel? Gunnstein has a fantastic library for doing rainflow analysis (https://github.com/Gunnstein/fatpack), but it would be great to see this put together with a codified method.
With respect to handling Design Code changes: I suspect this will be easy. I'm sure you're intimately familiar with how long it takes for Standards to undergo changes, and then when they do change, there's still errors! I can think of half a dozen off the top of my head in the Australian Bridge code which are still hanging on from 2017 😂. So I think the open-source community will be able to respond much, much faster.
Love the call to action!
Thanks Luke! Apologies for the slow response, I was unplugged over the holiday season.
Good points and I think we're on the same page.
One important distinction is that structuralcodes is not intended as an analysis package so all analysis should be outside of structuralcodes. Once you understand your demands or your design criteria - then you can use structuralcodes to check your members and ensure code compliance. There are no open-source projects that I know of that are aiming for this.
Fatpack is a cool package, have not seen that before. I'll add it to the master list of Python engineering packages... https://flocode.substack.com/p/023-the-best-python-libraries-for
I agree on the code changes, I don't see it as a major hurdle.
Thanks again for your inputs Luke, much appreciated, and a happy new year 👍🎉
First of all, I would like to thank you for the StructuralCodes library. For me, the most laborious task when using Etabs/Sap2000 programs is the difficulty of obtaining section moment-curvature and section damage limits. In order to obtain the relevant values, it was necessary to resort to the Xtract section analysis program, which had to transfer the values to Excel and process them. Thanks to you, I will now be able to directly define plastic hinge and assign it to sections (with my phyton codes). But I have a few questions I would like to ask you.
1) Will a cross-sectional analysis result made with the StructuralCodes library be compared with a proven program such as xtract or with a previously verified calculation?
2) Will it be possible to define the behavior of confined and unconfined concrete separately?
3) I live in Turkey. I would like to define my concrete model myself, which I created by taking into account the wrapped concrete behavior defined in TBDY-2018 Code. Does the StructuralCodes library allow this? If not, will it provide it in the future? If it does, will the analysis time be short enough?
4) Can a separate function be defined to idealize the moment-curvature values ((0,0), (ideal curv_y, ideal M_y), (curv_ultimate, M_ultimate))
My respects to you.
5) Will we be able to graph the strain-stress curves of the defined materials?
Hey James - to answer your some of short 'survey' questions:
1) I don't have the answer to this question right now as I'm new to collaborative library development!
2) Can treat it somewhat like a code committee (minus the politics) in that there are set targets for codebase updates and some level of 'peer review' after the actual updates to the codes/standards occur.
3) Would initially want "common" resistance checks to be covered (sectional, member), eliminating the need for in-house spreadsheets. Workflow wise would really depend on the portion of the building code or design standard we are looking to develop, could be simple (column design from axial loads derived using code combinations) to very complex (capacity design of LFRS elements) that would rely on some interfacing with a structural analysis package (whether open source or commercial) but the latter is perhaps beyond the scope of this library for now.
Thanks Phil, great input.
Regarding Point 2.
This is tricky, almost everyone in our field is already overworked and has zero additional time to allocate to maintaining an open-source project like this. I am not sure yet how this will work in practice. Some sort of streamlined code review process where pull requests only suggest one change at a time would make it much easier to adopt. This is an extremely important topic though so thanks for highlighting it.
3) - Agreed. Structuralcodes carries out the member checking process, after you've completed your analyses and understand your demands. This can be easily automated once the modules are set up.