Unique Solutions for Large Models: A Case Study of a 1.3 Million-Square-Foot Hospital

COLE FARMER: Hello, everybody. Thank you for tuning in today. My name is Cole Farmer. I'm a BIM manager at Arup. And with me, I have John Hall, who is the South Geography BIM leader at Arup. Today, we'll be going over a case study of a 1.3 million square foot hospital, and talking about the unique solutions that we came up with, and how it can be applied for large models. Through this, we're going to discuss the various workflows that we implemented, how we found model speed issues, and then where we go forward, and how effective our solutions were.

For our class agenda, we will start out with a project overview, then we will go into our problems that occurred and the solutions that we came up with. Next, in the future implementation phase, we will look at those solutions, and diagnose their effectiveness, and figure out how we want to implement those going forward. In the live session, we will have time for Q&A, but for anyone listening through the recording, feel free to check out our handout, which has more information for all the different topics we will discuss.

So, starting out, we want to go over why this class, why did we spend time to develop this class, and why should you pay attention and tune in to this class? So first off, with this, we encountered lots of unique problems, lots of things that might fly under the radar on a smaller project. When you start to magnify the scope and scale of something, it can start to increase the issues that come with that process. So we had lots of things that we were not prepared for that we had to work around with.

Additionally, our team has won an even larger hospital project that is getting ready to kick off. So we really want to make sure that we learn from our mistakes, and can put our best foot forward, and just keep that momentum going. We don't intend this to be an end-all-be-all solution. We want this to be a starting point. We want this to inspire out-of-the-box thinking so that way, everyone can kind of see different perspectives, and approach these problems from different angles, and so we can really start the conversation of how we do things. And we want to hear from you as well, how you do things, and really build off of what we've started here.

JOHN HALL: Thanks, Cole. I'm going to start with a project overview. We're going to talk about what the project itself is, what are some of the issues that we ran into, and how we rectified them.

So the project itself is a 1.3 million square foot hospital in Houston, Texas. It's a 12 story facility with the first five levels being podium, and the top seven being a patient tower. The mechanical floor on level four was designated to feed both up and down the system for all m, e, and p.

There is also a four story parking garage and central utility plant on site. Those were both being designed by a subconsultant. Arup itself is responsible for the mechanical, electrical, plumbing, and fire protection scopes of this project. And we were hosted on-- as the architect was the prime consultant on this, we are hosted on their BIM 360 site. And early in development, we decided that we were going to move forward with a live linking solution for all subconsultants.

All right, so when you get to project kickoff, and everyone's ready to start working in the model, they want to start working in the model immediately. While that is not feasible, it's very important as the BIM team that we have an efficient model setup process, so that way, we can get everything dialed in and out to the team to start their production.

One of the ways that we do that is through starting everything in a single combined model. So we have all of our disciplines in there. We're able to generate all of our sheets and views, and get everything set up exactly how we're wanting. And we can see everything from a holistic view to make sure this is going to be a cohesive set when it's presented all together.

So we use Rushforth Tools, which is a third party tool that we have access to to generate all of our views and sheets. We have an Excel file that maps all of the views that we want created with all of the view templates. And then through Rushforth, we use that to create all of those views per each level of the project. So it's a very quick and easy to get all the views we needed in one swoop.

Additionally, we use Ideate, the align command to align all of our viewports and viewport titles, so that way, they're all in the exact same spot on the sheet. So everything is very consistent and cohesive. You know that all of these drawings, even though they're from different disciplines, came from the same group of people, and that were very well coordinated.

One of the benefits that we saw with this project is that we were able to get a holistic view of the sheet numbering process. And we started with the sheet numbering strategy that the architect was using. However, we realized that the types of plans that we needed and the various iterations of all of those, we needed an additional distinction in the sheet numbering strategy, so we were able to coordinate with the architect and revise the project wide sheet numbering strategy for us and for all the consultants, to something that would fit everything that we needed. So we were able to do this early on without any major effect to any parties involved, and able to do this all in one location, which was super beneficial.

So like I said, we start out with the single combined model, went next to individual discipline models, so a mechanical model, an electrical model, and then a plumbing and fire protection. However, during the SD phase, we realized that this was not going to be enough. We were already encountering model speed issues, lots long sink times, so we knew we were going to have to split out further. So we started exploring different options, came up with a few different feasible solutions that we presented to our wider project team. And the Arup internal team determined that system continuity was going to be our driving factor.

So with that, thinking about the electrical team, one of the options we looked at was going by subdiscipline. So that would be like, having a power model and then a separate lighting model. However, because these disciplines work so closely together, right, you have the team circuiting the lights, you need all that power requirements, that stuff to transfer across, they really wanted that on the same model. So that's why we went with system continuity as our driving factor.

Looking at the way that the hospital is laid out, the level four mechanical floor was determined to be a good delineation point. We could have that and all the levels below be considered part of the podium, while all the levels above where the tower. So we could separate that for the electrical and mechanical disciplines very easily into a podium and a tower model.

However, with the plumbing, med-gas, and fire protection, they really needed the vertical continuity, right, especially with their gravity-fed systems and that sort of thing. So we had to make sure that they had the entirety of the building in their models, so we split into a plumbing model and a fire protection model. And because fire protection was going to be a little bit of a leaner model than the plumbing model, we included the gas with fire protection.

In addition to that, we had a site enabling model because there was existing structures on the site, so we had to do some demo, some rework of that kind of stuff, and we wanted that in a separate model, so that way we didn't have to pollute our hospital models with any of the phasing requirements, or anything of that sort. In addition, we had a separate single line model, which is atypical, because typically, we have our single lines included in the discipline models. But for this, with the addition of the subconsultant and some of the wider site characteristics at play here, we had a separate single line model, so that way, we could really show the integration of how the cup is feeding to the hospital, or to the garage, and that sort of thing. So that's why it wasn't a separate model there. In addition, we had separate models for each of our disciplines spaces, and we will talk about that in a future slide.

But so with this being an atypical model split out strategy for us and for our team, we had to make sure that there was a single source of truth that everyone could go to and reference. So we created a BIM onboarding document that included all of this, all the different work sets, that way, every single user would be able to reference that document to know which model they needed to be opening, which work sets they could have loaded, that sort of thing. And so we had this on the project OneNote, so it was a live document, and can constantly be updated, and reflect the current strategies that we're implementing.

So it also included things like our new workflows that we're going over, and our modeling standards, just anything that we wanted the team to know, because with a project of this size, it also includes a long project duration. So you're always going to be having a open, revolving door of people coming in and out, so you're always going to need to be onboarding people and getting them up to speed. So if we could offload that from the BIM team and just be able to point people to this document, it was a true time saver.

Something else that we use at Arup is a tool called IMAGINIT Clarity. We're able to connect this tool to our ACC, or BIM 360 environment, and it gets access to the models, and it actually can automate things like nightly prints of PDFs, being able to publish the actual models up to ACC or BIM 360, and Navisworks exports. So we use this as standard on all of our projects, but especially on this one, it was really useful because we have almost 2,300 sheets total spread across all seven models.

Early in the design process, the discipline teams decided that they wanted to have nightly prints so they could review what had changed, have the opportunity to take a look at stuff, coordinate things like that. So having a tool like this to be able to expedite all of that, and do it automatically is actually really useful. And it actually really expedites our drawing delivery process, because we're able to use the nightly prints, or set up special prints just for when a deadline is coming, so Cole and I have the ability to take those and start doing our drawings QAQC, along with getting it ready to be delivered to our end client. And this tool for this project has saved thousands of hours when it comes to opening, and closing, and loading models, and really printing all those on a nightly basis. It would be unmanageable if we didn't have a tool like this.

And on this project, we worked with the architect really early to come up with a set of enlarged plans that we were going to work to fully model and coordinate before we started taking that information and driving it out to the rest of the building. So the architect identified almost 120 rooms that they wanted to enlarge. So we took all those, created specialty scope boxes with a specialized naming convention of room and room number, so that we were able to expedite those all across the architect's model and our MEP models. And then once we created a parent level view for each level, we used RF tools again to be able to create the dependent views based off of those scope boxes. And with that, all of our rooms were exactly the same scope box throughout all of our models, and we were able to really get in there and coordinate that information before it all started to grow out across the entire project.

So now that we've talked a little bit about what the project was and how we identify stuff, now, we want to go to problems and solution, so the problems we encountered, and then the solutions we came up with to mitigate those issues. So one of our first ones that we did is, on general sheet notes, typically, with a single model, it's pretty easy to utilize Revit to keep those up to date. But as we grow across discipline models, and then across multi-models per discipline, we really were having an issue making sure that the model notes were staying up-to-date, because if a team member changed one in one model, it was on them to go in and change it in the other model.

And we were finding that that wasn't really happening, so early on in the project. We were having some issues with continuity across the notes. So we looked into a tool, talked to some of our team members, and started using a tool called Axiom, which uses Microsoft Word to be able to create and revise the notes, and then it loads it into there into Revit. So as we all know, the Revit text editor is a little funky, so being able to manage that in Word made it really useful.

And it actually allowed non-Revit users the ability to go in and review and edit the notes as needed. And then it just automatically loads into Revit. So it was really useful to make sure that across 2,000 sheets, all of the notes that we are trying to make consistent are consistent.

COLE FARMER: All right, and so again, early on, like I mentioned, we started having issues with model speed. So one of the tools that we use to diagnose that was the Interoperability Tools Model Checker, and the various health dashboard reports that they have that you can run. And so right off the bat, one of the things that it showed us was that we needed to do a selective purge of our unused content. As the design started getting dialed in, we started figuring out which systems we were going to use, how we were going to utilize our families, and that sort of thing. We could really start getting in and shaving off some of the unused content.

It also can show lots of different red flags. For example, it'll pull up and identify if your team members are using lots of model in place families, or detail groups, or that sort of thing. So it's a really good tool just to run periodically. And so through that, we are able to see and analyze the size of all of our linked models. And so that was the data that we used to create this graph on the slide.

And so if you see on the slide, the left hand side, those are our models that we were managing. And then on the right hand side, those are the interior fitout models. So you can see that model size of the linked models that we were using completely dwarfs the size of our models with a lot of them being over one gigabyte in size. So this was really contributing to a lot of the model speed issues that we were having.

And on top of that, one day, we showed up to the office and all hell broke loose. Our stuff was not working at all. We could barely get into the models. Everyone on the project team was messaging us, trying to figure out why they can't open the models, why it's taking forever to sync, and that sort of thing.

So we were able to use this and realize that the quantity of our linked models jumped basically overnight from about four to over 150 because of architectural modeling strategy change. They went from just having their four main models, to all of a sudden, using this complex system of attached Revit models that were coming through into our model. So on the next slide, we will take a look at an example of how this actually played out.

So this is the example of their level seven and eight model for the patient tower. So they started out with a single model for a typical patient room, and then they created a typical level model where they linked that typical patient room type one into it 21 times. And the patient room type two was linked into that four times.

And so for the level seven, eight model, it had two instances of that typical level model. So any time we were trying to load in these backgrounds, the typical patient room type one would be loaded in over 42 times just for this single model. So it completely just broke everything that we had. It really bogged down our stuff. So we needed to find a way to work around this.

And so just for a sanity check, we unloaded all the architectural models, and confirmed that our models still operate as expected. And we really noticed that improved speed. So we knew that the issue on our end was a result of the linked models that we had linked into our models.

So we did a lot of research, talked around people at our company, and found out that one of our coworkers had utilized CAD exports of backgrounds in a large airport project that had similar model speed issues. So after doing lots of investigating and talking through with our project team, we determined that was the route that we wanted to go. And so with that, our planned backgrounds would be the 2D exports, so we could condense all that information to just what we needed for those plans. And so 90% of our work could be done with the architectural models on closed work sets. And then when we needed to do spatial coordination, any sort of sectioning or elevations, then we could load those models and deal with the model speed issues just for those few tasks.

So what this looked like in practice is, we create a collector model where we linked in all of the architectural models. Then, in that collector model, we created all of our floor plans and RCPs for each level, and had it set up exactly how we wanted that to look for our background. And then we ran CAD exports of all those files, and then uploaded them to BIM 360, and then linked to those back into the collector model. So then once the collector model held all those CAD exports, we linked that into all of Arup specific models, and adjusted our view templates and everything, so that way, they were referencing those CAD files as the backgrounds for all of our plans. And then we set the architectural actual 3D models to be on work sets that are not visible in all of those views.

So as you can tell, this is a pretty tedious process. So we wanted to make sure that we were able to actually effectively implement this without any additional strain on the BIM team, and keep our backgrounds as live as possible, because as John mentioned, the team wanted to have that live linking aspect. So when we were looking at the Clarity slide, John talked about how we were using Clarity for nightly prints, but we also used Clarity to create those CAD files. So every single night, Clarity would export those CAD files and update them on the BIM360 side, so we always had those updates. Every single morning, you would have the newest iteration of those files.

However, when people were opening their discipline-specific models, loading that collector model still took a lot of time, because Revit was having to go into that collector model, and then go up to the cloud to get the current CAD files, get each of those updated, and then bring that back to the discipline models. So when we talked with our co-worker who had done this on the airport project, they had someone whose job it was every morning to open up the collector model and sync, so that way, it pulled down all of those updates so the users didn't have to do it on their end.

Again, we were trying to minimize the amount of BIM time on this task, so we use Ideate Automation, which is a great tool to actually schedule every day. It would open the model and sync, get all those changes, and have that pushed down to the collector model so the users would not have to load that. So everything was hands off from this point. We were able to just let all these tools run, and we had basically live CAD backgrounds.

JOHN HALL: As I talked about before, we really focused early on the project on having a live linked system for this project. And when we were coming up to the GMP deadline, which is the guaranteed maximum price, we wanted to-- our project team was really interested and really adamant that we needed to have some locked backgrounds, frozen backgrounds in order to be able to make sure that all of our discipline information is up to date based on the same background, and we're able to finalize our designs for that GMP deadline. Unfortunately, the architect was also working up until that deadline, so the live linking stopped being an actual solution for this.

So we needed to come up with a way that we were going to do this. And after some back and forth, we decided that we were going to pretty much freeze-- come up with an agreed date that we were going to freeze the architectural backgrounds on our own, we are going to design to that level. And then the architect could continue going up until where they needed to go. But we are at least from an Arup side, we are all going to be consistent with the same backgrounds.

So the way that we did that is, we actually took all of the architectural models that Cole was talking about, moved them to a separate folder on BIM360, and then went into our Arup models and repacked everything to those. So that was a tedious process. But we did that about a month before the deadline. And then a couple of weeks after, once we were clear, everything was good, and all the issues with that deliverable had gone out, we undid everything. We went back, went into our models and repacked everything back to the live stuff.

So it was a useful way to get frozen background, but it was almost two days of work on both sides of that deadline for Cole and I to go in and repath everything, do some quality checks, make sure everything was working, all the drawings were showing up, and then undoing it. So it wasn't the most time conducive way to go about it, but it did get us what our project team needed, which were those frozen backgrounds so that we were able to deliver for the GMP process.

And then what we really like to do is focus on internal tools to ACC or BIM360 that we're able to utilize as we're moving forward in the design, and the built in tools that are already there, we're not trying to reinvent any wheels. So a couple of the ways that we did on this project was working with the architect to be able to publish their overall plans on a weekly basis. And then we use BIM360 Compare to be able to compare the two documents, highlight any changes. It really allowed our teams to be able to see the hotspots in the building that had been updated over the last week, places to focus their information, something that they may have missed in just a regular update. But this is a pretty obvious, as you can see on the screen, red and blue, make it very obvious that something has changed, and you need to open your eyes and get in there.

We also did that with Model Coordination. We worked with them to create export views of all the architectural, structural, and then us for the MEP, and created a federated model that we were able to use the Model Coordination tool to go in and really identify hotspots again, in a 3D environment, places where there are clashes, how do we get them rectified, what are the design intents that we need to go, under the assumption we're not trying to create a clash free model. We're trying to-- it's a design intent. It's a buildable constructible model. So what are the areas we need to focus on and make sure we're getting that?

COLE FARMER: And so as the project kind of continues, it's important to make sure that the models are still being maintained, and that the users are doing everything that they're expected to do, and make sure that our standards are in place. So we had to do a lot of model quality checks throughout the life cycle of the project. And one of our primary tools that we use for this was Ideate.

And so we mentioned earlier that Ideate Align was used for all of our viewports and viewport title position alignment. So this is great to just have in our back pocket anytime something might have moved a little bit, which, as we all know, things do tend to move, even if it's pinned. We use the Align Command to make sure everything was back in alignment, good to go.

Ideate Explorer is basically a catalog of all of the elements you have in your model, and can pull up the different attributes associated with those. So one of those things that you can sort them by work set, and dive in to each work set, and figure out what has been modeled on that work set, and then easily move things around, and put them on their proper work set. And so with that, this tool can actually be used with all work sets closed. So as a very simple task of opening the model, all work sets closed, you can run this update thing, and it's very quick and effective.

Ideate BIMLink is a really cool tool that takes different Revit data, exports it out to Excel, where it can be easily manipulated and adjusted, and then you can push that back into Revit to get those updates. So there are tons of different applications for this. One of the ways that we utilize this was with our annotation crop.

With all of our plans and especially the enlarged plans, we noticed that the annotation crop was a little bit too large for what we needed, especially on the enlarged plans where the different plans were very close together, and so then it could create overlapping annotations and that sort of thing. So we really wanted to pool our annotation crops in close to the scope box boundary. So with this, we were able to get those dimensions of all four sides of each viewport, and minimize the annotation crop in a really quick and effortless lift on our side.

Another thing that we used was Ideate Renumber, which allowed us to go through and renumber all the details just by clicking the order we wanted them to be numbered, so we can make sure that we are adhering to the Arup BIM standards of where number one goes and that sort of thing. This was very convenient, because the way to renumber in Revit, as we all know, is not very convenient if you're trying to renumber detail 4 to be a 5, but you already have a 5, so then you have to make one a 5A, go, renumber it, then delete the A or whatever you need to do. So it's very tedious. So having a tool like Ideate, and the renumber function is very effective and easy for us to update.

JOHN HALL: And one of the things we do at Arup is, for all major projects, is called a digital inception plan. It's where we get together with the project teams and certain digital individuals, and try to come up with tools and workflows, either existing or new, that can benefit this project in a certain way. So as we were going through this project, we identified a need to map the electrical connector information from the med equipment, and kitchen models into our models, and keep that pretty much a live link. Typically, this is done through spreadsheets, and this is done through manual implementation.

One of the people on the BIM team was able to create a script that could automatically read all that information, create an electrical connector family in our model, exactly in the location of where that equipment is. And it keeps it up-to-date of what all the information that we need to pull into our schedules and drive our circuiting. And it allows it to stay updated, so it will actually send out a report and notify you if things have been deleted, added, loads change, anything that's changed. So there's always this constant upkeep. And it saved hours and hours and hours of time from our electrical team needing to do this manually. So this was a great tool that we created. And it's actually one that we're able to now utilize on any number of projects, and then edit a little bit, right? Is there something we can do mechanically, plumbing, stuff like that?

So our recommendation is really to focus on one or two tools as you're going through the project, try to build those out, really grow them to do what they're supposed to do. And then on the next project, you can implement it, and maybe create a new tool. And over the course of a year, over the course of four or five, six different projects, you're able to start growing this toolbox that you can use certain things out of that toolbox on any project and really speed up the automation, and not have to reinvent the wheel.

You've already done it. You've got it documented. You've done all that stuff. So this was a huge time saver for this project in particular. And on the next one, that's even bigger, it's going to be more.

So we've talked about the project itself. We've talked about some of the lessons that we learned, the issues that we encountered. So now, we want to talk about future implementation. So what did we learn from this project? And how are we going to use that moving forward onto future projects?

So our first big one was coordination with the architect, really building the relationship with the architect, or your whoever your clients are. If you're an architect, it's with the MEP firm. For us, we were the MEP, so it's with the architect. It's really building those relationships and having those conversations early. Know what you need to ask for, and really think about what you are looking for in a project.

Cole and I thought that we had all the right questions when we came to this. It went really well. I think there were still now things that we've learned on this project that we really would want to implement on the next one. So as we're going through the kickoff meetings on the next project, we're already asking these questions. We're already making sure we're setting ourselves and the entire project team up for success.

Things like model splits, how are you going to do it? How can we utilize what you're doing in order to drive what we're trying to do? Things like live linking, It worked on this project. Like Cole said, the CAD format was a little wampy and it worked, but there are some pros and cons to that.

So we really think that moving to a publish consume strategy would have benefited us on this project and will benefit us on the next. So we're looking to move forward with that. Things like Model Coordination, who's doing it, when are we doing it, what are we looking for, things like that.

So, you can go above and beyond so quickly on a lot of these things. So really trying to dial down to exactly what is needed, so you can minimize that either the rework or just the extra things that you need to do. We already know we have too much going on on a day to day basis to really just chase things for no reason. So making sure you have that conversation and the strategy, and planning is set for the entire project very early, and everybody agrees.

And then on this project, like we mentioned in the beginning, we have a sub-consultant that is working on two other buildings, the garage and the cup. So in the very beginning, we had some trying to determine the degree of interconnectivity we were going to use on this project. And it was decided that Arup was going to set up their models, manage their models. They're going to use the Arup standards. Everything was going to look the same, so it all looked like it was coming from the same company, things like that.

As we move through the SP phase, our sub consultant and project leadership team made a decision that they were going to completely separate from that. They were going to pretty much scrap everything they had done in SD, all the models we had taken time to create and standards we implemented, create their own models, and move forward with their own families, their own schedules, all that stuff.

It was looking back, it was not a very good decision. It didn't work the way we really wanted to. And we, Cole and I, were not part of that decision-making process, so we weren't really able to explain why it should go one way or the other. So just getting buy-in from all parties, and making sure that we're all aware of what we're trying to do, what are we trying to achieve for this project, and what their abilities are. I think maybe we overestimated or underestimated what they could do, and it really bit us in this project. And it's been a big fight throughout the entire multi-year of this project of us trying to keep them reined in and understand what's going on with their drawings.

And then standardization, I think we all can agree, standardization is one of the biggest things that we can do, especially across large projects like this. So just taking the time to make sure you understand what your standards are, and you're able to put those into place across multiple models. Things like sheet numbering, like Cole said, we did it all in the very beginning and came up with our sheet numbering standards, and stuff like that. But even then, for at least for electrical, they have over 130 in large plan sheets across multiple models.

So there were times that we actually got caught by having the same sheet number in both locations. Once we run our schedules, we can see that, we were able to get it rectified pretty quickly. But building that in and making sure that we have a way to check that, so we could get it quickly, and we weren't trying to chase it at a deadline, and figure out how we were going to renumber a lot of stuff.

And things like view templates, you know, especially if you have one discipline in two different models, if somebody makes a change in one, we need to make sure that it was getting changed in another. Typically, at Arup, the BIM team takes on a lot of that role. So we were changing view template, so we were able to stay on top of it, but it was really manual.

We never really found a way to keep those view templates updated across all the models. So that's something we're going to try to either look for or build moving forward on to this next project is, how is the way that we can automate this? And how can we make it easier for us in the management side trying to make sure that all these things are as consistent as possible moving forward?

COLE FARMER: All right. And so one of those things that we try to standardize is our workset strategy. And so starting off, we initially tried to limit the number of worksets that we had in each model just to keep things simple, keep it compact. However, as the model system grew, as there were more and more linked models coming in, we realized that we needed a lot more control over that. So we started creating individual worksets per each linked model type.

So because we were having to adjust on the fly, this is well after we've already split out into all of our seven different models. So this kind of created lots of rework on our end. it led to lots of discrepancies with how everything was being named, how it was being handled, and that sort of thing. So really building that in from the beginning, and having that understanding of how this is going to grow and expand. And so going forward, we want to make sure that we develop our work, that strategy with the end goal in mind, and knowing that these sorts of issues might come into play.

One of the things that we did do really well on this project was, we made sure that our worksets organized alphabetically. So as you can see on the image, we use an underscore prefix for the discipline specific worksets that the team would be physically modeling on. And then for the linked prefix that designated all of the linked model worksets that you could turn on and off. And then the Ref prefix was for linked models that were not intended to be visible in all views, things that were not anticipating will be printed, but for items like your spatial coordination, that sort of thing, for those one-off moments when you need them in there.

And then lastly, we had our shared levels and grids with the z prefix, so it was always in the bottom. And so one of the things that we did was, we made sure that all of our models were set to specify worksets when you open them, so that way, the team had no choice but to go through, review this. And especially with the amount of model speed issues we noticed when lots of the reference links were loaded, it was very critical that our team was paying attention to this, and selectively opening and closing worksets when they opened the model.

One of the other things that we had some issues with was our MEP spaces. So as we talked about previously, they ended up in their own space models. So initially, they were in the discipline specific models, but it really was an inconsistent process that each team kind of took different directions. There were lots of widespread errors, things like the space separation lines not being orthogonal, or intersecting lines and that sort of thing. So when we were thinking, loading, you're getting all these error messages popping up, and it really started to take a toll on our model speed. So that was one of the efforts that we did to affect our model speed, was pull those into their separate models.

However, this also had some issues because the parameters were not as easily transferable. So for example, the mechanical team was using their space model to analyze the various airflow data for each space, figuring out the pressurization, what's coming in, what's going out, that sort of thing. So they had their data coming from an Excel file that was being pushed into the space model. And they wanted to compare that with the actual airflow that was coming off of the model diffuser to make sure that they were matching and correct with their assumptions.

However, because they are in separate models, this didn't really work as seamlessly as we would have hoped. We were able to create a workaround to still reach our goals. However, having them in the same model would have been a lot more effective for this process. So going forward, we want to make sure that we can keep our spaces in our discipline models. So we need to make sure that our models are set up with that extra degree of flexibility, that there is that room to incorporate spaces, and that the model is not too large that it can handle the extra computations that are required as a result.

Additionally, we want to make sure that our disciplines are having a consistent approach, so that way, it's a lot easier to manage and make sure everyone's going about it the same way. So this is kind of one of those things that we want to make sure we want to talk with our team members, and get them onboarded very early on in the process so that we can get ahead of any sort of issues that we face like this.

And again, coming back to the CAD backgrounds, we had a lot of model speed issues as a result of the architectural linked model strategy. So switching to CAD backgrounds drastically improved our model speeds. So it was absolutely vital for this process, what we had to do. In addition, it was also a good benefit that we had consistent backgrounds across all of our disciplines. Having everything coming from that single collector model made it really nice, so that way, all of our drawing backgrounds look the exact same. So it was a very consistent approach, which was nice.

However, on the cons side, we still had to have those 3D models linked in for our coordination and various aspects like that, so we couldn't get rid of them entirely. So there were still tasks when you would need to have that model loaded and have the negative effects of that on your model speed. Additionally, with the CAD backgrounds, when you're working just off of the backgrounds, you can't investigate anything in that background. So you can't click on a line to see that, oh, this is casework, or this element is on this workset, or coming from this page. And you can't really do that with the CAD background. So you lose some of that workability that you have.

Additionally, we had a lot of issues with the room tags, because the rooms were being tagged in the collector model and part of the CAD exports. So they were stuck where they were. So you couldn't move them once you were in your discipline specific model.

So, if you for example, modeled a light in the center of the room, which is where the room tag happened to be, they're overlapping, now, your room tag is illegible, that sort of thing. So there were some issues with that that we had to work our way through. And then another issue was the background updates were delayed by a day. So it was not exactly live, but it was still close enough that we felt like that wasn't as big of an issue.