Crossing the Bridge: Mott MacDonald’s Digital Transformation

IGOR VARAGILAL: Hi. Hello, everyone. Today, me, Igor Varagilal, together with my colleague, Paul Briedis, will be presenting on crossing the bridge Mott MacDonald's digital transformation. As I said, my name is Igor Varagilal.

I've been working with Mott MacDonald for around four years now. My background is as a structural engineer. But I've been working with bridges and civil structures modeling and automation. And I'm based in Prague in the Czech Republic.

Hi, everybody. My name is Paul Briedis. I've been working with Mott MacDonald for about 18 years. I started out as a highway engineer and more recently, I've been working as a digital lead, supporting our transportation projects across the globe. And I'm also based in Prague in the Czech Republic.

IGOR VARAGILAL: Why do we think you should stay in the room? What's in it for you? If you are a client or an asset owner, we believe that we have developed our capabilities using the software that we are going to show and the workflows, we developed a couple of good workflows as well. And this is all to meet the client requirements.

And a big advantage as well is that this improves our ability to respond to change. That could be the highway, driven by highway or railway or by engineered changes. The importance of this is that we can get value by meeting our client and by our client information requirements.

If you are a product user, if you are the delivery team, we believe that there are different solutions for different problems and that no two projects are the same. And we are going to show you our digital transformation from 2D to a parametric and information-rich model delivery.

We want to show you our mistakes, and we want that by the end of the presentation, you will be able to learn from it. During our presentation, the bridge engineering details will not be covered. And what we are also going to show you is a sample of the bridge projects that we have delivered Mott MacDonald. So it's a sample of the projects that we worked on, on a large multi-discipline project.

So in the last five years, we've been working on tender and detail designs projects. And we wanted to move from a 2D AutoCAD approach to information-rich 3D parametric delivery. And to do that, we found that this process takes time and effort to achieve. And it also calls for different range of solutions and software, a collection of tools. And we started that process using a Revit Dynamo Civil 3D and Navisworks.

Also, as our information management platforms, we used ProjectWise and BIM 360, but those were mainly dependent on the client and their requirements. We also worked a bit with Inventor and InfraWorks and more recently, we've been working with Rhino and Grasshopper and exploring their power to export this geometry to Revit.

The idea here is that we wanted-- or one of the main reasons or the outcomes of this process is that our team, the capabilities of our team, was steadily growing. And we wanted to do this transformation. We wanted to go on this journey because we wanted to embed the digital delivery in the way that we work.

We wanted to be the ones driving innovation and improve the efficiency of our workflows. And one of the more basic reasons that we wanted to do better, we wanted to deliver more by doing less. As I said also before, we hope that by the end of this presentation, this will benefit you and your team to forecast and plan the improve of your project delivery.

PAUL BRIEDIS: Let's have a look at the journey we've taken over the last five years. For today's presentation, we've selected four projects to go through, the first of which is a collection of rail projects in Australia. They were some detail design projects. The second was a major highways project in the UK. Again, a detail design project.

The third one, which is a tender project, again back in Australia. This was a milestone project for us, with the program constraints and the volume of work we had to generate and complete in that time. So that was a huge learning curve for us.

And the last one we're going to finish off is a project which we're currently working on. Again, it's a major highways project, detail design in the UK. And this is where we are adopting a quite advanced workflow in terms of the bridge delivery, connecting the analytical and the graphical models to further push the efficiency in our ability to deliver these projects.

So we're going to look at the key challenges both then and now. So from five years ago up until today. So a lot of these challenges will be familiar to those listening in. And we've broken them down into three categories, the first of which delivery. So what are our challenges? Our client requirements. The project requirements.

We all know this is the main driver and one of the biggest challenge that we often face with delivering our projects. And this is what pushes us in the way, a lot of the times in the way that we want to go. And we're always trying to stay one step ahead to have those capabilities to meet those requirements, if and when they come around.

Responding to changes, Igor mentioned. When anyone who's worked on a bridge project, being able to respond to a change in geometry from a highway or a rail geometry is a fundamental aspect of the way we're delivering projects. As we know, the geometry of a bridge could change twice in one project or it can change 10, 15 times, some of them large, some of them small. And that's a really fundamental part of how we plan the more technical model production and model delivery side of our work.

The quality and the consistency. So we, like any other engineering firm and consultants who's delivering work, we want consistency and quality across our outputs. And this is no different from what we want to achieve as well.

Single source of truth. We all know about this as well. And again, we're constantly trying to have our model production and now we're touching on this latest project, the analytical, as a single source of truth. So that's a big challenge for us to try and achieve.

Let's go into another, the second category. It's the technology. So the capabilities of our team and those who are working on our projects. This is one of the big factors. Every time we work on a project, we don't always have the A-team. We don't always have those expert, elite users of Revit and Civil 3D and whatever it may be to work on these projects. We have a combination.

Some people have 10 years' experience and can do a lot of amazing things. And they'll be partnered with a couple of graduates who are just learning and eager to get involved. And that's something that always becomes a factor for us. And it sort of reflects the real-world challenges that we all face.

The limitations of this technology. Well, this is why we're here at AU. We're learning about where last year's limitations are no longer, and this is what we're looking forward to next year. So what the software was capable of doing five years ago is different from where it is now. And it'll be different again in five years' time, of course.

So these are the challenges that we have to work with. The information management. Your BIM 360s, your ProjectWises, your [INAUDIBLE], whatever it may be, these are the challenges that we have to work with. And we're talking about on these project examples large-scale multi-discipline projects. So managing big volumes of data, big teams across continents and time zones.

This is a major challenge for us. And I suppose just to highlight the point here, getting the right information to the right person at the right time is fundamental to everything we do. And it remains a significant challenge for those members of the team who are trying to ensure that that is indeed taking place. So that's a key challenge for us obviously.

Lastly, winning hearts and minds. So we started off our journey five years ago from a 2D delivery, and we all started there at some point. And some people may still be there. We want to transition. We wanted to transition to a more intelligent way of delivering projects and a team of people who technologically have the skills to use a software and have some, let's say, forward thinking and a bit more of a vision.

There are always those parts of the team that are not involved in this and maybe sort of part of the pure engineering or some other aspect of the delivery. And we can't progress in a more advanced or efficient way or we're limited by how fast we can progress if we don't have everyone convinced and believing that the new ways of working and the doing more for less kind of approach that we're all trying to strive for is everyone's onboard on that. We need that.

It's not just a pretty looking 3D model. How many times when you started working in the BIM or the digital world that that was something that was said to you when you've created something and you want to share it with an engineer. That's some of the things that we're challenged with.

And this is an evolution, not a revolution. This takes time. So what we're going through here, this is five years, I've said, over 4 projects that we've selected. This is a gradual step change as we go and learning from our mistakes. This doesn't happen overnight.

I said before, your challenges could be different. But a lot of these would be common to you as well. So hopefully, setting this scene. We're going to get on to the projects. We can sort of start to have a common way of evaluating how these different aspects list on this slide sort of touched on and how we've tried to overcome these challenges.

So we'll get on to the first project. So collection of rail projects in Australia. So this was a set of detail design projects for a major railway upgrade. Within our scope was a design and documentation of two road in three rail bridges.

The client information requirements in this case, we had to hand over a native Revit model. And the level of detail was three with some minor attribute information. So fairly standard kind of delivery, let's say.

This was our first bridge project for our team delivered in Revit. We of course, had done Revit projects prior to that in other practices and other different assets we were working on. But this was our first one done in Revit.

So the software versions we're working with, we want to touch on this just so we can sort of just get people thinking about the limitations or the challenges we're working with. This was Revit 2017. We had a bit of Dynamo with this. And the geometry of our road and rail was pulled together using Bentley RailTrack and Bentley InRoads. Igor.

IGOR VARAGILAL: Thank you, Paul. What did we do on this project? As I said also before, we started by using the technologies we had available, and this was Revit and Dynamo. A bit of Dynamo to create our models, and we also used Navisworks to visualize them and to just check the information.

Here's an example of one of the road bridges. And what we were trying to do is to understand the time and effort that it would take us to create the model. And we also wanted to understand what value does that bring.

We viewed it in between parentheses, that convince part, we wanted to-- because this was our first project, we wanted to convince ourselves that there was a value to put this time and this effort into building this Revit model.

Then, we also worked with the drawing production. In here, we can see an example of a traditional 2D approach of a drawing in AutoCAD versus a Revit output that we had from our models. We see that it's quite different. But this is exactly what we wanted to do.

We wanted to understand what was the time and the effort that we needed to input to create the same output, to create the drawing that would be industry accepted with their standards.

And we wanted to understand what will be the value that we would get out of putting that time and effort as well. So again, we have in between parentheses the convince. We wanted to convince ourselves and the engineering team, the team that was working with us in the project, that there was value in using this workflow in Revit.

PAUL BRIEDIS: So just touch on the challenges here. So again, after each project, we can go through the challenges and the lessons learned. So limited resources available. First project, only a handful of people in our team that had the skills. So that was our first challenge.

The drawing production. So yes, that was the challenge. But that was exactly what we were doing, investing time and effort in parallel with the traditional 2D delivery of those drawings, to do this again, and we'll see how far we could get using that Revit model.

Again, the value from the model, the challenge. So when we produced this model, it wasn't really sort of taken on board as being sort of a key deliverable. How do we then get the most out of it? It was more just like that's just the output, a bit of that's a nice 3D-looking model, yeah.

The engagement with the engineering team. It's not as though there weren't limited engagement, per se, but it's the value as to the production of this model gave that-- the generation model that gave the engineering team was somewhat limited. So that was our challenge we were trying to overcome. So putting it in the front of mind and trying to make this as a normal way of working was a challenge for us.

The lessons learned. I'll sort of continue on this. The parallel delivery with traditional 2D delivery of the drawing production, the design, that was a really good approach for us because we didn't want to risk and go down the path of, yes, we went. We can create from single source of truth approach the drawings from the Revit model. So we had that sort of fallback position of the traditional delivery was going to still be there.

Early planning and engagement. So what are we going to do for next time? Well, yeah, we need to engage a lot more with the team, early planning. What type of geometry you're going to get from the rail and the road geometry, so from BRT and InRoads, what are we going to get from them? How do we use that information to generate our models?

Expanding our model capabilities. Of course, we saw what we had to do. We saw the effort, and that means, right, we've got to go and invest time and effort to our capabilities. And I think everyone comes across this issue, the better Dynamo organization. Whilst the Dynamo scripts did their work, they were pretty messy. So we've all come across this, I'm sure.

And last one, Understanding the time and effort and value going into modeling. So that's our first project. And now, that just sets the scene as to where we started. Now, we're going to build up sort of the complexity and the challenges that we had there on.

I'll introduce this project now, and then we'll go back over to Igor. Major highway project number 1. So a quick rundown of the project itself. Detail design, several structural types. LOD4 and minor attribute information. So we're now getting a more complex, more detailed model. So that means we had to up our game in terms of Revit, the use of Revit and our capabilities.

We're working with a digitally mature client and for a lot of people, I think that's actually where there's a struggle or barrier perhaps. So when we're not sort of pulled upwards from our client to progress in advance and think about intelligent ways of working, it can be sometimes a bit inhibiting to our growth. And we were very fortunate enough to have this digitally mature client to continually challenge and push us and try and get the most out of this investment.

Revit 2020 Dynamo and same with Civil 3D was what's being used Igor. Oh, no. I'll just finish this. Here's just a couple of slides of the models at the end of the day, which we produced, some rendered images from Navisworks. And yeah, this just represents both the complexity and the form that we had.

So there's a steel footbridge in there and a couple of other steel girder bridges. And yeah, so all in all, that was the delivery over about one and 1/2 to two years. So Igor.

IGOR VARAGILAL: To achieve those beautiful renders that we just saw in Navisworks, we had to model it in Revit initially. And we did it by breaking down our model. So we could have modeled the bridge all in one go. But also due to the client requirements, as Paul said in the beginning, that we had the LOD400, and we needed to have some kind of specification for our elements and to break them down element by element.

So we did that by placing a couple of the elements that were mainly driven by the highway's input, the strings that would get from the highways input. We modeled those using Dynamo. And a couple of examples of those elements are the deck, the barriers, and the girders.

As for the piers, the piles, or the pile caps, those were modeled manually because we also believed that there was no need to have a Dynamo script to place these elements. They were changing, yes, but we could easily model them manually in Revit. And we would have the same value in doing so.

A special attention here is also to the levels. This was also a client request to have each of those elements assigned to a specific level. So you could see here there is an abutment level. There's a pier level. So those elements that are assigned to that level are also the pier and the abutments. So that would be easier for the client and for us to see these elements in Navisworks.

So this all started because our key challenge, and as we said also in the beginning, this was the main challenge that we faced. And then for sure, a lot of you here in audience will face it as well. We want to respond as quick as possible to the highway geometry changing. And we believe that we created a workflow that allows for this, that we were able to allow for this quick response for these changes of the highway geometry.

To do so, not only we needed to have the workflow set up like this, but our scripts that we were using, we believe that we have to keep them as small as possible and as easy because if they are small, they are going to be easy to debug. This was also a project where we started to have more people, more resources using Revit and Dynamo. So in order to do so, we wanted to keep them as small and easy to debug as possible.

And one thing that I didn't mention, but we also have a Content Library for modeling these bridges. So the piles and the piers that you see here. But the big problem is that that Content Library was not accessible. We wanted to have that Content Library as accessible as possible.

And we found that if we needed to click or spend at least two minutes to get that content, it was a challenge. It was a problem. So this was a lesson learned that we will touch on, that we needed to have that value. We needed to have that Content Library more accessible to our users.

Very important as well. We broke down the model, but in certain elements, as we can see here as the abutment that was modeled in place, we didn't model or we didn't break down exactly as it should have, let's say, like that.

And this is a very good example to understand the why and the how we are modeling. So it's a very good example to understand the downstream, to understand the construct stability in this case. We're talking with our contractor, engaging with our contractor. We could understand that maybe we needed to model this element, this abutment a bit differently with the wing walls and with the wing wall bases. The foundations of the wing was separate.

Another thing that we did in this project was the drawings. As Paul said in the beginning, this was our first fully delivered in Revit detail design. So we actually had to produce the drawings.

As we all know, maybe Revit is not the best tool for linear infrastructure. But we still felt like we were in a good position to try with the skills that we had and that the growth that we were-- the fact that we were going with our team, we wanted to try and achieve a product or the drawing output that would be accepted.

But it cannot be understated how difficult and how time consuming this process is. Yes, we have drawings here that look good and that was our output. But it was very, very complicated to achieve this. And as you all know, a couple of challenges that you face when you are creating these drawings, if our bridge is curved, both in a plan or in an elevation, it's a challenge to create a long section, to create an elevation of that bridge along that curved alignment.

If we sometimes annotate or we create some text notes for some of the elements, if the bridge after moves position or if there are some changes, we need to move those annotations. We need to adjust it. And also, if we want to annotate to some of these elements that are not perpendicular to that view, it can also be very complicated.

So these are just a couple of the challenges that we faced creating these drawings. I'm sure that you all have different challenges when you are trying to do these drawings. But very importantly as well, during this process and after, we found out the importance of having a very consistent and robust Revit template.

This is our starting point for our Revit models but also for our drawing production. So we needed to have a Revit template. And in this case, in the beginning of this project, we did have one. But the more we used it and the more we broke it down, we realized that there were some things that we needed to improve. And we used this experience as a building block for the next project so that we wanted to achieve consistency in our drawings.

And we wanted to have a final product that is consistent across all of the bridges, all of the models that we are working. And this sometimes can be difficult to achieve in a major project when we have multiple people working at the same time.

Just on the drawing production as well, what we did also was we developed a Dynamo script that was highlighting the elements that were modeled in a 3D environment. So these are the elements that we see here in red.

And we did this because we believed that this gave us a lot of value when we were looking into these drawings, not only for us, but also for the engineering team when they were looking into our drawings in Revit. And a good example here is that if you see this typical Section 1, there's the bracing elements. They were not modeled in 3D. And you can see here that they're not highlighted in red. And this is very obvious for some people of this sentence.

But the more elements you model in your model, let's say in your Revit model, the more elements you included, the more detail you're going to have. So then the easier the drawing production becomes. So you don't have to create details, 2D details, to insert this into your drawings.

And very importantly, and this is a sentence that we sometimes say, is that the model doesn't lie. Like, what we get in the model is what really is there. But to achieve this product, sometimes we need to use a couple of tips and tricks to get to this final product. So the model doesn't lie, but for us to get to that final product, we do need to use a couple of tips and tricks.

PAUL BRIEDIS: So we're going to now touch on something else that we-- the first time we trialed something for our team on this project, and this was the 3D RC detailing and drawing production. So we were using-- so we'll just point out that this was a Revit 2020 project. And the tools we had available to us within that release, we really found it challenging with the geometry that we had in our models to be able to get that RC detailing working.

So getting all the geometry, the conditions of the RC caging and so on was very challenging for us to achieve in the decks and the abutments and other elements, just because we weren't working with just nice linear shapes, but we're working with, say, bridges that had a super-elevation on it.

So the deck is sort of warping as it goes along the alignment. And this proved to be very challenging for us. We invested the time and effort to do this, to find out what value we would get from it. And whilst we had the Revit technicians and the engineers working as part of this trial quite closely together, there was a lot of benefits.

Obviously, the visual side of things, to be able to understand what it looks like and how we can interrogate this, not just in the drawing. So there was benefits. But the downsides were just, again, the geometry from our structure model itself was really-- it wasn't working certainly as cleanly as we needed it to be for that to be an effective way of delivering this output.

So we learned a lot of lessons here. And I'm sure there's a lot of people who have come across or come to the same conclusion or a similar conclusion with a bridge or sort of an asset which is of complex geometry.

Just I'll pop back just quickly on this one. It's worth noting as well, Revit 2023 has had a lot of improvements, or work done rather, into the features for RC detailing and documentation and so forth. And we're currently working on-- so doing an evaluation piece of what we went through using Revit 2020 on geometry like this and then doing the same geometry but using Revit 2023 because we always have to be looking back to where the blockers were in the past and where the software functionality then improves, which can unlock some of those or sort of remove those barriers. So Revit 2023, some of you may be looking at this as part of this AU. It is something that we're keen to explore further on.

Another little quick one. Pretty easy. So this was about how do we connect the highways team with the-- or the highways tin surfaces to generate in Civil 3D to the bridges team with their models complete in Revit. So some of you probably well and truly know about this, but some of you may not.

There is a published surfaces function within Civil 3D where you grab your surface, you publish that surface to BIM 360. And then from there, when you're working with that person who's on the-- a Revit user who's on the same project, they can then import that topography and have that linked directly to their Revit model.

And this is just another thing that we needed to put in place to get the coordination and the information transfer to the right people at the right time. And this was a really good workflow to make sure that was happening.

Does this solve the problems of the geometry changing with the highway and the bridge? No. But it did give us a really good connection and clean connection for not just the interior in the model but the drawing production. So yeah, the final design and existing topography model was referenced cleanly, accurately in the Revit model. So that was a good little trick that we applied. And yeah, saved a bit of time, and it certainly helped us.

Lastly, so one of the things that we tested as part of the time working on this project was Civil Connection. And this is something that's been around for a couple of years now. Here, I've got a video.

So what we've got here. So Civil Connection is all about getting-- I've got the Civil 3D model on the left, a corridor model. And then using the specific Civil Connection nodes in Revit, getting a generic model then are generated in Revit to represent that subassembly, so that sort of portion of the Civil 3D corridor.

And you can see here in the demo, and this is all set up, and it's nice and sort of it's all working. Whilst this worked, and rather it works, we sort of struggled a bit to try and use this on the live project because it has a couple of conditions which have sort of quite obvious that the Civil 3D corridor needs to be nice and clean and complete. And it needs to be showing everything we need.

But also, we found it sort of challenging to-- like, stability issues were a bit of an issue for us. And sometimes, like, one of the big things is the Civil 3D corridor, the team they had, it doesn't take long for anyone who uses Civil 3D, it doesn't take long for a Civil 3D corridor model to get really quite large.

So when you're having all that information in one model, it's hard to get that connection. So a bit of a challenge for us. But that was a good lessons learned. And I suppose that was always trying to challenge the way we were using, as Igor mentioned, breaking down the model into the separate elements and having those Dynamo scripts in the Revit, creating those different elements, the decks, the girders, and all that kind of stuff. So two ways to get to the same point. But we sort of, I think, still preferred the way we were originally working. Igor, do you go-- go through the challenges, Igor.

IGOR VARAGILAL: OK. The challenge. The first one, as we mentioned, and we talked about it, it was the drawing production and the reinforcement detailing. Yes, we did it. But yes, as we said, there was a lot of challenges. And for this complex geometry, there's still a lot of tips and tricks that we need to use to achieve that final product.

The next one was to model the complex geometry. There is a couple of elements like the abutments or some decks or girders that were a bit more difficult to model. And although we could achieve that in Revit, it was sometimes difficult to get that or in some examples like the abutments, where they are skewed, and they are following different planes, it was very difficult sometimes to model that in Revit.

Well, to do this, this was a very Dynamo-heavy workflow. So to do this work for you, you need to have expertise. And it was essential to have that expertise. And we also used this as a challenge in the beginning, but we also used this as a lesson learned or we used this as an opportunity to upskill the team that we have here with their Dynamo capabilities.

And then, as we said also, we needed to have consistency between the Revit families that we were using. Because we didn't have that Content Library, sometimes that consistency was just not there.

PAUL BRIEDIS: So looking at the Dynamo scripts, the lessons learned. Those Dynamo scripts. So keeping that small and easy to debug and easier to use for those sort of more junior staff members was really important. We wanted to give these staff the tools to do their job so they weren't reliant on the more experienced team members.

And again, in our experience, that sort of raised the bar on-- sorry. Excuse me. At the minimum, sort of lower capabilities and where we're trying to grow team members, this certainly enabled that to take place. So the challenges we didn't have available to the team easily accessible, that Content Library. And that's a lesson learned. We really need this library to get efficiency and quality and consistency.

Model breakdown constructability, as Igor mentioned. That constructability and understanding what's happening to the model once it's generated. You start thinking differently about, well, how do I generate it, and what information do I need to include in that, and so on? That was a good lessons learned for us. And that really highlights the importance of-- it may seem very sort of fundamental, but ensuring that we understand what our client or our contractor client needs or wants from this model.

And understanding that early is really what we all need. For instance, it's not just looking at a scope and delivering it. But diving a bit deeper can really enhance the way we work and have that better working relationship.

Published surface is very helpful. And yeah, so this is another one we haven't touched on before. Getting the Revit team who are generating these models, getting the fundamentals of Civil 3D is actually really-- yeah, it's quite important because one of the things we found is, say, a highway geometry will be updated.

And OK, there's that model over there sitting within Civil 3D, and we need to extract the feature lines as an example. Well, that is a very-- for anyone who uses Civil 3D, extracting fetch lines from a corridor is a really straightforward process, but unless you know how to do it, you're relying on someone else to go and give you that information. And whilst you've got the capabilities there within the team, we want to avoid situations where those highways users and so on are not available, I'll have to give that to you in a couple of days.

Well, no. Let's go and do it ourselves in a managed way so we know we're working with the right information and so on. But that kind of thing was sort of a bit of an eye opener that it wasn't just Revit that staff needed to know. They need to know the basics of Civil 3D to keep them moving.

Right. Project number 3, rail project in Australia. So this was a tender project delivered as part of a DJV. 130 kilometers in length for this project. So our scope was the design and documentation of 68 road bridges and rail bridges and viaducts. And the total length of all of those assets were 15.5 kilometers. Like any tender project that we've worked on, it was for anyone-- the program was very challenging, and this was very challenging.

This was done during COVID, the height of COVID. So we're all working at home. And that was very, very, very, very challenging. So again, we've got a bit of Revit 2020 Dynamo. And for this project, we had our rail and road geometry generated in 12D, which is a very common rail and highway platform within Australia and other countries.

A little bit more about the project itself. So this rail, this alignment, it's a tender project. The rail line was continually changing. When we say changing, we're trying to get the optimized alignment for this length of track. And for 130 kilometers that is very challenging, of course.

To get some sort of metrics as the scale of the change, so the responding to change piece that we said is a challenge, this was nowhere more apparent in any time, any project worked on with this one. So of those 68 structures we worked on, approximately 50% of those had to be updated every week and, yeah, full stop. That's a major challenge for us.

So for that reason, not knowing actually that it was going to be that challenging we still-- it wasn't going to-- not knowing there was going to be that many structures that had to be changed per week, we knew that we needed an innovative approach to respond to change. And also, we needed to develop an innovative approach to extracting the quantities of each of these structures.

And so we'll go through that. So we've just got a quick little fly through on the federated model. And so this is just one portion of the road. So we're just looking here at a couple of the viaducts we have. We've got lots of cut and fill areas, which are sort of highlighted as well. And we're just trying to give you an idea of what we're working with here.

So the geometry itself, I think it was LOD 3, I believe, for this project. And the scale. So the 15.5 kilometers we mentioned, this is one of the key points here. So this is really, really a unique project for us and something which presented some very, very significant challenges to overcome, both from working with our engineers and using the software and using the technology. Over to you, Igor.

IGOR VARAGILAL: Thank you, Paul. So to achieve that, our first step was to define the substructure and the superstructure elements, the geometry itself. And this was defined in the matrix in Excel, and in that matrix, we had the attributes for these elements, the substructure and the superstructure elements. And these elements were some dimensions and some graphical and nongraphical attributes.

The first step was to define a code for that substructure. This was all driven-- it's important to say that this was all driven by the engineering team. They were the ones owning this matrix, this Excel spreadsheet. There was a specific code that was assigned for each of these substructure elements we see here. And what we did is that we created a Revit families with a Revit family type, with the same code as this Excel spreadsheet.

As I said, these graphical/nongraphical attributes were defined in the same matrix. We have examples of the pile diameter, the pile spacing, some for the columns, and for the add stocks, and there is more attributes that were not here shown because the matrix was, in fact, very, very big.

And also, some nongraphical information such as the reinforcement ratio or the concrete class for those elements. And very important about this matrix is that this was being updated several times per week. And because of that, and this is something that Paul mentioned, and I would like to stress, because of that, we needed to be really flexible and agile to respond to these changes of this matrix, of this Excel spreadsheet to reflect those changes in our Revit families.

The second step was to define those families, to create those components in Revit. We have here a little video of what we commonly call the Revit Master Model. This is where we had all of our Revit families. And during the lifecycle of the project, if a model needed to get a new family, this is where they will have access to those Revit families.

This is also where we would, with the Dynamo script that we created, we read that first matrix that we had initially shown with Dynamo. And those updates on that matrix, on that first matrix, would be represented.

So if, for example, column diameter would change from 2 meters to 2.5, in a click of a button, we will get that change reflected in our master model. So then, the modeler would have confidence that it was getting the most updated family. It's also very important to note that although I'm only showing the Revit families here, but in the master model, this is also where the important information for our project was living. So any update to the title block or to the textiles or line styles that we would need to create our drawings, this is where the modeler would get those changes.

So the Revit Master Model was, in fact, serving as a live Revit template. It started from the Revit template that we had, also a Revit template that was, as I said before from the previous project, it was improved from what we had before. But then, what we did here is that we started this Revit Master Model with that template, and we were changing that live. And we had that flexibility.

Well, the next step is actually to build our structure. Our first input was the rail design string. So this is what we would get from the railway team. And we will also get the same design string, but it was draped to the topography. And this is where we would read from our Excel spread-- from our Dynamo scripts.

Thanks again to the engineering team that was very engaged, and it was driving us to do more and better. Again, in an Excel spreadsheet, we would have the definition of the structure. We would have the elements of the structure defined there. So there was a couple of manual inputs that we had to have because the input from the railway team was not always the same.

So we needed to define sometimes the offsets from where the bridge started, compared to where the D double-G string was starting and where it was ending as well. But that's one of the inputs that we had to have. And the next thing was actually to run the Dynamo script and reading those changes or those distances on that same string.

And using the code that I previously mentioned, the code for the substructure, we would be able to place those elements along that string. So here is the example of the abutments. We also have the example of our substructures. And these are, in this case, an ROP with four piles.

The superstructure was also placed, reading from this Excel spreadsheet. So there was the definition of the super T girders and then the deck placement on top of it. And as I said, this was our structural definition matrix. So this was all thanks to the engineering team that was driving again this spreadsheet. Over to you, Paul.

PAUL BRIEDIS: So another output of our delivery was understanding the quantities of the structures throughout the project. So we needed to find-- we're moving. It's very fast. We're responding to change very well. And we've got a good process to update the content and get that content to the individual modeling team across those 68 models and update it.

But we then had to several times a week extract the quantities from each of those models and build a sort of master quantities breakdown to then engage with our DW partners and the project partners to understand what's the cost, the program, the carbon, all of that.