Using groups in Revit seems to be a no brainer; we create groups for elements that are repetitive and yet we are still able to quantify them as if they were individual elements. Modify one instance of the group and it will be updated everywhere in the entire project. One can even exclude an element from a group instance to make an exception.
Over the years, Autodesk has improved upon this awesome tool, but has not made it more flexible. If we create a group the wrong way, Revit gets upset. You don’t want to see Revit upset. In actuality, Revit actually gets confused. The main problems occur when groups contain elements that are constrained outside the group. In the simplest form, if one was to create a group of elements including a door, the wall where the door is hosted would need to be within that group. And in many instances the wall could have a top constraint that is not applicable for all instances. It is also common to create groups for casework that rely on the walls for placement, but the walls are not part of the group. In class, you may have heard me say, groups should be “self-centered”. These types of constrained can also cause problems in Design Options.
That being said, yes, there are restrictions that one should be aware of when implementing the use of groups throughout a big project. Here are some tips.
In a previous post, I discussed “What Causes Revit Data Corruption?” and some model maintenance suggestions, “Revit Project Maintenance Guidelines”. I hope you find this article and those listed here helpful. Reach out with questions or comments anytime.
Best Practices with Revit Groups: Rule #1 http://www.seandburke.com/blog
About Best Practices for Groups Autodesk Knowledge Network
Technology is transforming the way that buildings and infrastructure are designed, constructed, and operated. It’s helping improve decision making and performance across the buildings and infrastructure lifecycle.
To learn more about how Autodesk’s Connected BIM processes goes beyond design, leveraging the power of the cloud to help make possible practically anytime, anywhere, collaboration, data continuity across a project, and provide deep insight to help improve decision-making,
Join us and register now for Microsol Resources’ weekly webinar series, starting on Tuesday, January 9 at 11 am EST.
If you missed these webinars, you can view the recording of all of the Connected BIM Webinar Series here.
On January 9 at 11 am EST, learn how Collaboration for Revit and the BIM 360 Team service can empower a project team to collaborate and manage all aspects of a construction performance. Register here now.
On January 16 at 11 am EST, take the first step in preparing for the next era of technology-driven change for construction and discover how you can dramatically improve margins, capitalize on an increasingly globalized construction market, and deliver better outcomes for your clients. Register here now.
On January 23 at 11 am EST, Technology is radically disrupting the way buildings and infrastructure are designed, built and used. Discover how Autodesk is connecting to the future with tightly connected BIM tools and processes for the buildings and infrastructure lifecycle. Register here now.
Stay in the know. Register now for our weekly webinar series.
The ‘too many missing elements’ error in Revit is one of the vexing errors in Revit where the application does not allow one to open the project file. In this case, the file is practically unrecoverable and the team will have to consider restoring a previous version of the file. However, it is possible to ‘catch’ this error earlier when it appears only when the ‘audit’ option is checked by opening the file. If corrupted, one can prevent the corruption from progressing to the next stage that renders the file unusable.
This article assumes that one is able to open the model and that the error appears when ‘Audit’ is checked when opening the model. If the user is unable to open the model, then there is not much one can do other than restoring a backup or opening a support case with Autodesk and attempting to recover the file.
The following are two images of the error message from the original Autodesk Article.
Why Don’t Existing Solutions Always Work?
The first solution usually may not always work for two reasons:
The journal file does not provide a complete listing of all the element IDs involved in the error.
Secondly, Element Ids are not constant between Revit sessions. This means that the element ID for an element missing today will not be the ID for the same element from an archive saved yesterday. This effectively makes the copy/paste solution practically impossible to implement.
The second solution is to simply find an archive of the project that will open without the error (when Audit is Checked) and restore the same. This may result in loss of work and is not anybody’s favorite option.
This solution was originally suggested by Autodesk Support. The premise is that this error is caused by one or more corrupt family components. So the solution was to extract all families from an un-corrupted archive of the model (un-corrupted here means that one is able to open the model with ‘Audit’ check) and load those families into the corrupted version of the model. This overwrites all family definitions including corrupted versions and thus rids the project of the error. Family extraction from a project can be automated by going to Save As > Library > Family.
The challenge with this approach is that large projects contain hundreds of families and loading them manually becomes tedious unless the process is automated either by using a macro or a dynamo script.
This solution attempts to identify and delete the corrupt family or families by editing (Right-click > Edit in the Project Browser) each family in the corrupt project individually until Revit crashes when attempting to edit the corrupt family. Once again the challenge with this process is the tediousness of the task given the number of families in the project. However, a free tool like the Family Size Reporter does the exact same action automatically.
When the crash does eventually occur, the user can note the last family that was being processed by the Addin to identify the corrupt family (boxed in red in the image below). The tool does require a bit of babysitting in order to clear any errors that may pop up during processing.
Once the corrupt family has been identified, one can re-open the model and locate the family in the Project Browser and delete the family (via right-click) or replace the family with an un-corrupted version from the library or archive. The project should open without error after this (when ‘Audit’ is checked). If there is more than one corrupt family, this process will have to repeat as many times as needed since each run of the Family Size Reporter will crash when processing first available corrupt family.
The advantage of this solution is that there is no need for an archive and the recovery process is relatively quicker with minimal loss of work.
Features the latest informative and technical content provided by our industry experts for designers, engineers, and construction firms and facility owners.LEARN MORE