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.
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 👍🎉
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.