Tekla Podcast #3 – Developing individually and as a team (Jānis and Artis from UPB)

Podcast #3 features two key employees of UPB, a Latvian company that has been around for about 30 years. They specialize in integrated solutions for complex constructions, and with almost 200 engineers on the books it’s no wonder they have been a continued success in the industry.

Our first guest is Artis Aizstrauts who is the head of R&D of UPB; an accomplished researcher with over 20 publications to his name. The second guest is Jānis Goldmanis, an R&D Project Manager with more than 9 years’ experience.

Watch the whole interview video from here:

or listen it in audio format here:

Don’t have time to watch the whole pod? Skim the questions and answers summary in a written format below! 👇

When did you start with Tekla Structures, and what other systems did you consider?

Jānis: We started using Tekla in 2006, at which point all our design work was being done in AutoCAD, and there were two things that we needed to improve. First was our design accuracy, and the other was our design speed. Accuracy is obviously important, but more so for us because the majority of our work is exported (to Scandinavia), and it is very costly to fix design mistakes on site when all your resources are in Latvia, but you are working on a site in Sweden. Working with Tekla’s 3D BIM means that you can for example check much easier for clashes in your model using the software. Tekla ensures that our designs are much more accurate.

And then of course, speed. At the time, we were doing a lot of large parts with prefab steel construction, and Tekla is very good with this. The main reason being the numbering system, whereby you can simply model everything you need, and then Tekla automatically applies the numbering and tells you which parts are the same, meaning you can quickly reduce the number of necessary drawings. Prior to that, we were working with 2D DWGs, and we were basically creating drawings for each beam. This meant each beam had a unique set of parts; you didn’t check if the next beam was the same or not – you simply went on to the next one with another drawing. From experience, Tekla solved most of these issues, heavily improving design speed as well as accuracy.

3 years ago, we were also choosing software for our Facade division. It too was lagging behind, using the same 2D DWGs, but our projects were becoming more and more complex, to the point where they were becoming unmanageable. We were investigating whether Tekla was also a good solution for this scenario; comparing it against competitors like Revit and Solidworks. In the end, we went with Tekla again, because of the ability to create very large and detailed models. Despite the fact that the facade projects were much more complex than any steel or precast project. The other platforms we researched were either lacking the amount of detail, or the scale.

Do you remember how it was when you first started to use Tekla?

Jānis: In one word: Inefficiency! When we started there was a lot of trial and error going on just to figure out how to work with the software. Only a few people did any official training, and we had no internal processes in order to distribute their newly-acquired knowledge to others. As a result, everyone was slowly figuring it out themselves; how to work with templates, even just how to model simple things, how to create drawings, and so on.

Over the years we have figured things out. Then, 3 years ago when we were implementing Tekla in our aluminium curtain walls, I would say it was much faster. We already knew all of the basic Tekla functionality, and we simply put together a team of experienced Tekla users and experienced facade designers. Together we made different proposals of how we should model facades in Tekla. It took something like 3 iterations of models, and after each one we revised the approach. In the end it took around 9 or 10 months to determine the best way forward.

“There was a lot of trial and error going on just to figure out how to work with the software. Only a few people did any official training, and we had no internal processes in order to distribute their newly-acquired knowledge to others.“

If someone were to start a new company, how would you recommend they go about it?

Jānis: If you’re just starting out, I would recommend against trying to automate everything from the start. It definitely helps if you have an expert consultant who can show you the possibilities, but you should learn the basics of how Tekla works before moving to more complex things. If you jump too far ahead without a solid foundation of knowledge, you will inevitably make mistakes.

You mentioned different automations; what have you done over time?

Jānis: We have made an internal system for our precast wall panels – and we have a set of components that need to be used. We have an organized system whereby for example, when a user needs to do something with a wall panel, they will already know which components they need to use. There are also pre-set attributes that users can use very simply. Creating this organised system was the first thing that really helped us. Of course, you can’t make components for everything, but you could easily make them for 80% of what needs to be done.

What we are currently working on is working for the whole model. If we know the steps we need to produce one single element, we can then automate the steps required for thousands of those elements. We simply need to look at the model and figure out, what is the 80% here that we can automate?

You mentioned automations for an entire project rather than just some elements; how do you manage to do this?

Jānis: We’ve used Grasshopper; it’s a tool that allows you to quickly try your ideas. You can quickly create a concept that maybe isn’t foolproof, but it shows that it could work. And based on that, we are able to take things forward and make applications.

For example, 5 years ago, engineers needed to add lifting anchors to the wall panels. What usually needed to be done was to look at the unit properties in order to find the weight of the panel. They then needed to calculate the necessary resistance of the anchor, after which they would search the catalog for a suitable one, and then insert the anchor into Tekla.

The first step to build this process was to create custom components for anchors in Tekla. Prior to this, everyone was simply creating their own models and naming them. So, we made the models available. Next, in order to make the process smarter, we exported all the cast unit properties to Excel, where we could then calculate all the necessary anchor types for each using a formula. This is where Grasshopper comes in. It easily reads this data, and then references a large number – thousands, easily – of wall panels in your model, then based on the data in the spreadsheet, applies the appropriate anchors to all of them in your model.

In the last step, we don’t even need the spreadsheet. All of the calculations end up being done in Grasshopper, you select your whole model, and then all the anchors would then be inserted automatically. Once we have refined it and ensured that the accuracy is up to spec, we created it as an application instead.

Now, this application inserts all the correct anchors according to the panel weight and the detailer just has to check for clashes.

To take things further, we are currently looking at each type of action that you need to perform on an element, for example, insert anchors, insert reinforcements, insert perimeter reinforcements, create seams and so on, and creating these automatizations for all of them so that we can do these actions for the whole model at once.

To illustrate it, one very useful tool, Connection Classifier, is available in Tekla Warehouse. See the demo below:

The next thing on our agenda is vertical seams for precast panels. The interesting thing here is that we have to join it together with a calculation model. With that, we are matching the calculation model with the Tekla model; we export the forces in the seams from the calculation model; and then insert necessary embeds in the Tekla model. We can do this in one fell swoop for roughly 80% of any given model.

“We are currently looking at each type of action that you need to perform on an element, for example, insert anchors, insert reinforcements, insert perimeter reinforcements, and so on, and creating actions for all of them so that we can do these actions for the whole model at once.”

What calculation software do you use, and how is the connection between them and Tekla out of the box, and have you developed anything to improve on that?

Jānis: We use 2 main calculation software – Dlubal RFM, and StruSoft FEM-Design. I think the ability to convert from a Tekla model to Dlubal RFM is good enough out of the box, provided you already have existing guidelines on how the Tekla model needs to be created. However, the need for minor adjustments means that out of the box, the connection between these two softwares cannot be seen as a “live link”. After converting Tekla model to the calculation model, we resume working in both platforms separately. If there are any minor changes in the Tekla model, we add them as well to the Dlubal RFEM model.

What we’ve done – as an additional tool – is we have an application that compares both models and tells the user whether or not they are the same, since it’s possible you might have made some minor adjustments in Tekla that you did not apply in the other. It’s a huge help.

Your Tekla dev team has been busy! How big is the team, and what is their main focus?

Artis: We don’t have a simple separation between R&D and dev team; what we do have is at any given time is between 20 and 30 people working in R&D behind ~200 engineers. This is because the development of an application is the last step. For development, we have 3 or 4 people full time, but all the other people are working with the R&D stuff, with the components, with Grasshopper and so on. Important is to figure out where engineers are struggling, spending too much time on manual work and how can we bring up our efficiency. Only once we have figured it out, made the plan and all the preparations and sure everything is in a final state, etc, does it become a new spec for the OpenAPI application development team.

How do you approach the task of new developments?

Artis: I would separate two main themes for development. We have operational development which is focused on how we can optimize daily tasks; so for example, how can we do the things we are doing even better, faster, more accurately, and so on. The other is high-level R&D, where we look at the specific improvements and high-level projects for the future. This team is smaller than the other one. An example of what this team does could be, around 5 years ago, they were playing around with Grasshopper, and as a result today, Grasshopper is a regular part of our processes.

As far as development planning is concerned, it’s an agile process. Obviously, you cannot do this work without engineering knowledge, and finding a dev with an engineering background or qualification is quite difficult, so instead we have a team of both engineers and developers, and they work together closely to achieve the desired outcomes.

Regarding the smaller R&D team; can you elaborate on anything they are working on?

Artis: One of the proof-of-concepts they are working on at the moment is machine learning – essentially, can we, and if so, how can we use it in our industry? At this stage, the answer is not clear, because our industry is naturally very precise, and we’re still looking for various applications of the technology that has a satisfactory degree of accuracy.

They also work a lot on integrations; mainly with the facade unit, as that unit is a lot newer and there is more work to be done and gains to be attained.

Jānis: I would say that right now, the simplest and yet most complex thing we are working on is holes for the facade (aluminium profiles). We have these very detailed aluminium facades in Tekla; a complex model with roughly a million parts, and what we are trying to work on is how can we – with the push of a button – get the profile from Tekla to C&C. Currently, there is a problem around how to get all these holes in Tekla, and it’s a question of do we even want all of these holes in Tekla. At the moment there is an export problem, so we don’t currently create the holes in Tekla, but with each year, we get closer to the point where Tekla will be capable of handling these additional holes (around 20 per profile) and also export them. This is a big problem to solve for engineers, because if changes are made to the model, it can result in changes needing to be applied to millions of holes! So we need to ensure they are correct by means of a tool – it’s impossible to check them all manually.

How do you share new tools once they are created? How do you decide which tools should be used?

Artis: We have a Quality Control system and documentation. Engineers can access it any time and get the latest versions of anything we’ve documented.

Regarding tools, we have an internal synchronization system, whereby we upload every tool, template, and so on that should be included in an engineering toolset – not only for Tekla. In that system, we organize it clearly, by project, by company, and so on. From there you can assign these toolsets for a particular team, and thusengineers on each team have only the data they actually need on their local machine.

Jānis: This “internal warehouse” ensures that if an expert-level user generates a template, attribute file, etc, in around 10 minutes, everybody connected to that project or team will have it on their machine as well.

But on to the part about communicating the existence of these files. We actually use analytics to get an idea of how many people are using different tools. For instance, we know how many drafters we have; we know that we have a very good function for them; but if we see that fewer users of that function than we have drafters, then we need to send out a notification to them all so that they know that it’s there to be used.

Previously, we also tracked clicks in Tekla and we could record how long it takes to create an element drawing. From all that data, we could see if there were any discrepancies; for example, we can determine why some users are much faster than others at completing certain tasks. It turns out that in many cases, the faster user is using functions and tools that the slower users were not aware of, and that makes it easy to improve efficiency.

Finally, about a year ago we simply started interviewing people. We had records of all the tools and functionality we had by role (eg. engineers, drafters, etc), and we basically asked if they were aware of each one, whether they use it, or if it wasn’t applicable to them. There we get information about what tools the engineers are aware of and they will get hints about what to explore more.

If an expert-level user generates a template, attribute file, etc, in around 10 minutes everybody connected to that project or team will have it on their machine as well.

What are some of the “rookie mistakes” you notice are common among users? How to avoid these mistakes?

Jānis: In my experience, one of the most common rookie mistakes is that when a new user starts, they accidentally delete something! That can be very costly so you would want to put measures in place to help avoid this.

Overall, regarding rookie mistakes, one of the applications we have developed is called “Model checker”.

It assists in checking an element for things like whether you have used the correct country grades, types; is the element acceptable for manufacturing, and so on. This application runs during the night and literally goes through everything according to a pre-set set of rules. This way we eliminate most of the mistakes that commonly are made by newer users.

Continuing on this quality theme, though; we also make sure that everything is always checked by at least one fresh set of eyes. This is quite a rigorous process involving checklists, which means that the task is always treated as a serious one.

Any tips on getting the best performance from Tekla?

Jānis: First of all, I would recommend learning all of the manual Tekla functions. Master them. Once you’ve done that, you can make a big leap forward in productivity by learning about Parametric Custom Components. Finally, start working with Grasshopper, or another (e.g. C#) scripting method. That makes parametric components even more efficient because you can automate processes with them that you would otherwise need to do manually. This will literally save you hundreds of hours.

How do you decide when to perform tasks manually, versus developing something to automate the process?

Jānis: On one hand, we have a lot of statistics, meaning we know how engineers are spending their time. This allows us to evaluate how much time we could save by creating tools. But in our case, we are also fortunate that management encourages us to pursue these gains. We simply need to make sure we compare how long it would take to develop a tool versus how much time it will save in the long run.

For instance, with Grasshopper, it’s very easy to develop these concepts. And when it comes to completely automating a modelling process, it’s just a no-brainer; we commit to developing tools for those things.

Then of course there are the developments that empower users to do things that previously weren’t possible.

Artis: To go a bit further on developing tools, think of the black box / white box concept. With one huge black box tool, it completes many tasks for you but you have no idea how it gets done.

With more smaller white boxes, you’re able to see and understand how everything gets done. We prefer the white box approach, because with transparency and ability to cross-check things comes trust in the process and the maintenance is much easier. It cannot be understated how important that is.

How would you like to see the level of tech outside of engineers offices catch up to what happens in the offices over the coming years?

Jānis: I would really like to see improvements with augmented reality precision level. It would be fantastic for quality checking to be able to get a virtual element or even the whole building anywhere you want.

Artis: I would really like to see an uptake in the use of Tekla model information. We have great 3D representations of a project with a lot of information, but so many factories and construction sites are still using only 2D drawings and a lot of BIM model benefits are not used.

In Tekla Podcast #5 episode we will have guests from ALTO 4.0 who has developed coworking with UPB an ERP system Alto ERP and there you can see how they are using Tekla model information in their ERP system and in the whole project work-flow.

Any last comments or advice?

Jānis: Never stop improving yourself! You should always have some drive in you to learn something new. It’s akin to investing in yourself and your future.

Artis: I would say that also, we need to improve our digital level. Our industry is kind of lagging behind, and I believe we need to introduce more digital solutions, particularly around working with data. We need to keep working to raise the bar in terms of digitalization; doing so will afford us new opportunities, and everyone will benefit from it.

---

AUTHOR

FIND THIS USEFUL? SHARE IT!

YOU MIGHT ALSO LIKE