Autodesk Vault can produce PDF files from drawings, Inventor Drawings and AutoCAD drawings, and so can Sovelia Vault. This blog post focuses on the added value and the benefits of using Sovelia Vault with your Autodesk software.Learn more
Strategies for dealing with large projects in Autodesk Revit
As Autodesk Revit has become the favoured tool for construction design, and the benefit of Intelligent models has been realised. Larger and more complex construction projects are now being produced and documented in Revit, such as airport terminals, sports stadiums, hospitals, to name a few. Inevitably, the models are getting bigger and pushing the limits of the hardware. During this blog I look at some strategies for dealing with large projects in Autodesk Revit.
The ideal scenario for Revit is to have everything in one project file. The complete model, along with all the necessary Views placed on Sheets. Schedules, Legends, Design Options and Phasing all included. That way everything will interact, and we can take full advantage of the parametric change engine to have instantly revised projects as per the Revit philosophy.
However, real world experience tells us that it’s not always practical to have everything in the one project. Huge file sizes, depressingly long opening and synchronisation times, the risk of catastrophic losses if the project file gets corrupted. It’s enough to keep you awake at night!
So, logic says we should divide the project into multiple files to safeguard against some of these worries and make it easier to handle. But what is the best way to do this?
Unfortunately, there isn’t a single answer as each project will have its own considerations and best approach, but here are some scenarios to help point you in the right direction.
The Small to Medium Scenario
First of all, always have a separate ‘Site’ file containing external works, topography, surrounding context, etc. and a ‘Building’ file for the main building. These can be linked into each other as required. I would suggest using the site file to set up coordinates, then position the linked building on the site and publish the coordinates back to the building. If there are multiple buildings on the site, then a separate model for each building should be created. In this scenario the sheets and schedules should all be kept in the Building file. This should be the standard workflow for all but the smallest Revit projects.
Where there are multiple buildings on a site, the sheets and schedules that relate to specific building should remain in the individual building file. For sheets and schedules that span across buildings then a separate ‘Sheet’ or ‘Container’ file should be considered. This file will have the buildings and site linked in, with views, annotation and sheets created in the file. Creating drawings that relate to linked models presents two issues that we cannot get around. Firstly, we can’t edit the linked model without opening it. If we spot an issue with the model while annotating a view, we must open the model to edit it. Unfortunately, the functionality that allows us to edit reference files ‘in-place’ in AutoCAD or Microstation isn’t possible in Revit. To add to this, we either need to unload the model from the container file or close the container file in order to open and edit the building model, adding to the time taken to make changes. A workaround is to have two copies of Revit open, one with the container file open and the other for editing the building models.
The Large Building Scenario
On very large buildings it seems that splitting it into smaller pieces is a good solution to maintain efficiency, but we must be aware of the overhead of dealing with many linked files. So, before dividing the building model into separate files, consider whether it can be managed with Worksets in a single file. Worksets can be opened or closed as required, so by dividing the model into worksets, parts can effectively be closed or even not opened in the first place. The effect of this is similar to having separate files, the objects in a closed workset have minimal impact on the performance of the open worksets. However, it is incumbent on the users to assign the model objects into the correct workset as they are created – which doesn’t always happen. Also, the file will still be a very large, single file for the purposes of saving, synchronising and potential corruption.
When it comes to splitting individual buildings into separate models, several things must be considered. Foremost is when to split the model. The early design stages will benefit from a single model. While there isn’t too much detail and many options are being considered, a single model per building is almost essential. Once the project moves into design development, then splitting the model must be considered.
A situation I often come across is a model that has become too big and is virtually unmanageable. By this time, synchronising and saving could be taking 10-15 minutes or more, creating new local files could be taking 20 minutes plus, therefore users could be losing up to 2 hours per day waiting for files to open, save and synchronise. Multiply that time by the number of team members and it becomes a significant loss in productivity. I’ve come across some projects where the users never close their local file. Each evening they just synchronise and go home, leaving Revit open because they’re frightened of not being able to re-open or create a local file the next morning.
If you’re already in this situation, it might be too late to split the model into manageable pieces. The problem with splitting an existing project file is that all the parametric relationships between the objects, along with all the annotation, such as tags and dimensions, applied to the model is likely to need recreating. A large project is likely to have thousands of views and sheets. Potentially, the majority of these would need checking and re-building. Therefore, splitting an existing model means stopping work on the Revit project and spending several days, if not weeks, splitting the model, re-linking them back together in a container file and re-building all the sheets.
This shows that it pays to have a strategy for model management from the outset. Once the design development stage starts, a decision needs to be made as to whether the model will be split and, if so, how will it be divided.
First, decide how to manage the sheets across the project. I would suggest having a container file with the multi-building scenario. Then, how to divide the building model? Once again, there isn’t a single correct approach, it will always depend on the individual building. If it’s low rise and covering a large area, such as a stadium or airport terminal, then zoning may be the best approach. The main consideration with zoning is not only how to define the zones, but also how to manage the interface between them.
A high-rise building could be divided vertically, or a mixed-use scheme divided by the uses. I commonly see the fabric of the building being used to split the model, i.e. the external envelope, core and structure, interior fitout, furniture all in separate models. This works quite well as each model is relatively small and quick to work on.
With all these scenarios, there is always a risk of the annotation being lost when the links are re-loaded into the sheet container file. If objects are replaced in the model rather than just edited, or families edited and re-loaded, this may cause dimensions and tags to be deleted when the model is re-loaded into the sheet file. Upon re-load a warning will appear telling us that ‘dimensions will be deleted’ and our only option is to delete them or cancel the re-load – which isn’t really an option. If this does occur, then expand the warnings and take note of the affected objects so they can be reviewed and re-instated if necessary.
In conclusion, large projects need to be divided into multiple models to keep them manageable and minimise risk of lost work. How to split them should be considered at the outset to prevent the model getting too far developed and making it virtually impossible to split at a later date. Having an office strategy defined and implemented on all but the smallest projects will mean users are already used to working in that way and will prevent models from getting too unwieldy in the first place.
Can we help you with your Revit models? Get in touch with us for a consultant like myself to assist you with a particular project, or talk to us about scheduled or private Autodesk Revit training courses we offer.
In this blog post, we take a look at why you should use Autodesk Docs in conjunction with Autodesk Takeoff when producing quantity takeoffs.Learn more
In part 1 of our “Hybrid office: a longer term strategy” blog series, we discussed the technology routes your business can take if you are likely to keep an emphasis on home working. In this blog post, we discuss the options available if your business is more likely to take an office at core, home at edge approach.Learn more