Imagine having to go through over 10 000 values and manually input them into a model, each one taking several clicks and maybe 10 seconds. That’s 100 000 seconds, or 28 hours of painstaking work. What a nightmare, right? Then imagine having to do it again. And maybe again. This article includes a case study that shows the potential of programming used by structural engineers.
This post was written by BIM Corner’s Guest Author, Johanna Riad.
All software has limitations in its functionality. Software developers walk the fine line between having enough functionality in their program and having such a complicated program users become dizzy (I’m talking about you Revit). The more diverse the users, the more difficult it becomes to cater to everyone’s needs. This doesn’t make it any less frustrating for the user who knows what they want to do, and are just missing the button to do it.
One way of tackling this problem is to use programming to create your own functions through an API*. The following section will describe an example where this approach proved successful.
Table of Contents
1. Case study: WoodHub
The engineers at MOE had a project-specific issue that they needed to solve. They were working on a large office project in Odense, where several timber buildings were to be built on the same concrete basement. To work efficiently, they divided the project into several smaller FEM-Design models, which they could analyze and design individually. However, when modelling the basement, loads from the buildings above needed to be transferred and applied to the basement model.
Of course, this could have been done manually, reading all the individual point and line reactions in each superstructure model, and creating a corresponding load in the basement model. This would need to be done for each load case. Any time there would be a design change, the loads from that model would need to be updated.
Luckily, there was a better way. Writing a script to transfer reactions from one model as loads to another was possible, thanks to the FEM-Design API*. A custom script was developed in Grasshopper as a collaboration between MOE and the Strusoft API group. The script works in the following way:
1. Reads a FEM-Design model specified by the user, where the analysis has already been run and results exist (model 1)
2. Deconstructs all the point support and line support reactions for each load case
3. Creates new load cases from all the load cases in model 1, unless specific load cases are provided as input
4. Creates point loads and line loads in the new load cases. The user can provide a limit so that loads smaller than a certain value are omitted. Line loads are simplified according to MOE instructions, so that unnecessary peak values caused by the nature of FE programs are smoothed.
5. Reads a second model where the new load cases are to be introduced (model 2). The script uses the FEM-Design coordinates so it is important that model 2 is placed correctly in the same coordinate system as model 1.
6. Load cases and loads are added to model 2.
7. Model 2 is saved and can be opened in FEM-Design
. . .
Any time that the load transfer needs to be updated, the script can be re-run.
2. Advantages of programming when you’re a structural engineer
The opinions in the following part of the article are quite subjective, based on experiences in my career so far. I have experience reaping the benefits of programming as well as falling into some common traps. I hope this section will give food for thought for structural engineers that are interested in leveraging programming in their work.
Knowledge in programming can be extremely useful as a structural engineer. I will describe some of the areas where I see the most obvious potential below, and in the next chapter move on to some of the risks.
2.1. Repetitive tasks
When a certain task needs to be repeated several times (in the same project or between different projects) there is often time to save by automating the whole workflow or parts of it. This can be related to the structural design, as well as for example creating drawings or documentation. The case study above is a good example of a repetitive task that is relatively easy to automate. Other examples could be writing the same information on several drawings, designing many similar columns, creating calculation reports, continuously uploading a 3D-model to a web portal for sharing and much, much more.
2.2. Large data quantities
In large projects, the amount of information can start becoming difficult to manage. Being able to take a step back from the individual data objects and look at the larger picture can often be vital. If you’re comfortable working with data to quickly create graphs, visualizations, and other types of summaries you can get a bird’s eye view of the project. This could allow you to see important patterns. For example, if you visualize the carbon footprint of your proposed structure, you may see that a certain part of the structure is causing a large part of the footprint. Knowing this, you may be able to address the issue through redesigning that part of the structure.
It can also be a good idea to use this approach to check for errors. If certain elements or results break an expected pattern, it becomes obvious in appropriate visualizations. When doing this, a good idea is to think of how to make it easier for the human eye to see errors, such as applying color coding to the graph below. Making visualizations like this often only requires quite basic programming knowledge.
2.3. Sensitivity analyses
As structural engineers, we always make assumptions when we (try to) convert reality to a model. The assumptions we make are sometimes generally accepted to be true, but a lot of the time we must use our own engineering judgment. It is important to understand the implications of our assumptions, and one way to gain a better understanding is through sensitivity analyses. If we run a simulation to see what effects other assumptions give, we can take those results into account when designing. Other stiffnesses, creep and shrinkage values, construction sequences etc. can sometimes completely change the structural behavior, which is very useful to know.
2.4. Optimization problems
Another important area where programming is useful is when dealing with optimization problems. In structural engineering, this is often related to saving material, which in turns saves carbon footprint and cost. Doing optimization manually is often too time-consuming, but with the aid of programming, it is often possible to optimize your structures a lot more. Optimizations can also deal with other topics than saving material, like for example saving time through improving the construction sequence or finding ways to optimize the production, transport or assembly of building elements.
3. Challenges!
Having described some of the possibilities of programming, I also want to raise some of the associated challenges and risks. I think that we need to be very aware of these to avoid a development which in best case is unideal and in worst case directly harmful.
One important challenge is that programming is a separate knowledge area from structural engineering. It takes time to learn programming, time that could be spent improving other engineering skills. It can be debated what skills are the most important for a structural engineer to build and focusing too much on programming could potentially make structural engineers more rigid and square (as opposed to creative and able to see nuances). One might want to hire programming specialists, internally or as consultants, to be able to focus on the core structural engineering skills oneself. On the other hand, some basic knowledge of programming is useful to understand the potential and know when it is suitable to ask for help automating a workflow.
Another challenge is the tendency to try to adapt the problem to the programming solution instead of the other way around. The risk is that we over-simplify the task to be able to find an “efficient” programming solution. The solutions created this way are anything but efficient if they fail to capture the real complexity of the problem. This relates to the tendency that I often see where the scope of the proposed programming application is too big. Sometimes engineers try to solve the whole design process through a parametrical model. In my view, this is a kind of utopia for engineers who wish that reality can be reduced to something purely mathematical and logical. Reality is always more complicated, and there are practical issues and exceptions to rules and subjective opinions all over the place. A combination of automated and manual workflows is often a much better idea.
4. Summary
This may seem disheartening at first, but if you think about it, it is actually quite uplifting that what we do as humans cannot completely be replaced by programming. It is the balance of creating programs and automations that work well together with human input and judgment that I find most interesting in my job.
*An API is a programming interface which allows users to communicate with a program through programming
Check out other articles about Grasshopper on BIM Corner:
Computational Thinking-Why should engineers care about it?
