Revit Purge - So Good You Use it Thrice

 

How often do you use the Purge command in Revit?  Have you ever noticed that the icon includes a broom?
Probably your Revit model manager is the only person allowed to use it because you could accidentally remove important stuff from your project if you don't know what you are doing.

If you are allowed to use the command, and you know what you are doing, then you may not be aware that you need to run the command three times in succession to do the job properly.  This has been the case for the last few years since the Factory added the capability to purge materials.

Why Purge three times?

1.  The first time it will select all the unused elements that it is able to:

2.  The second time it will pick up materials and assets that were used by elements purged the first time

 3.  The third time it will pick up unused material assets that were previously associated with the materials purged the second time

Why does it do this?  Well it seems unable to handle purging the materials and assets at the same time as their parent elements - it is all too much for it.  It is not consistent with other aspects of the purge command - for example if you purge an unused group, Revit will also purge items that are in the group providing that they are unused elsewhere.  So Revit can do it all in one go if it wants to.
My guess is that different people coded the software for material purge, and they probably didn't follow the same rules.  Or perhaps there is a technical reason for the inconsistency?

Either way, I am very, very happy that we can actually purge materials because it did not used to be the case a few years ago, and it was extremely tedious deleting materials one by one.  I know that on some projects  it can take half an hour to run the purge command, so it is annoying to have to run it three times.

Why is Purge Dangerous?

Why not let just anyone run the purge command?  Well, apart from the time it takes, it can remove important stuff from your project that is tedious to reinstate - here are some examples:

• Curtain Wall Mullions.  Purge will remove some unused system families or types - like all those tricky corner mullions.  It removes all unused types, including the last one of each mullion system family.

• If you try to place a mullion then you discover that no mullion family is loaded - not something that a novice user needs to deal with.

• Purge does does something a bit different with some annotation families: eg. Spot Elevation families;  it removes all but one unused family - so it will not remove the last one (it may not be the one you want to keep).   Typically you will actually want several different spot annotation types (at least one each for plan and elevation).  This means that most of your annotation standards can be blitzed in one command - and they are laborious to set up again.
• The same goes for other annotation types like dimensions, text etc - although they are easier to reinstate.

To get around this problem, I suggest creating a "setup" phase that is earlier in time than "Existing" and placing one of each type of mullion, door family, annotation etc that you do not want to have purged accidentally.  The elements in this phase would not be visible if they are demolished in the existing phase.

Purge Does Not Remove Everything

Despite it being too easy to purge some things, it can also be hard to remove others:
Where one family is referred to by another that is retained in a project, Purge will not remove either (even if unused).  There are numerous examples, each of which behaves differently:

• It is impossible to remove either of the Stair path arrow system families, despite the fact that most people only want to use one as their corporate standard.
• Basic walls cannot be purged if they are defined as part of a stacked wall, even if the stacked wall is not used.  Nor can they be deleted in the Family Browser (by right-clicking) until they are removed from the Stacked Wall definition.
• Railing Subcategories like Top Rails (and Handrails) will not be purged if they are part of a railing definition even if that railing is not placed in the project.  However, you may be able to delete them from the Family Browser:

• If the railing has other elements beside the Top Rail you try to delete, it allows the deletion, with a warning message (in which case the Top Rail vanishes from the railing); 

 

• However, if the Top rail is the only element in the railing that has been used, Revit will not allow you to delete the type

• Railing Supports behave differently (as they are not system families):  Revit allows deletion of the supports, with only a warning message

If you really wanted to, you could go through and manually delete all kinds of families  and types that are used in other families, but it is a laborious process, which makes minimal impact on a project size.

Reducing Family sizes

A similar technique can be used in Revit family editor to remove those unwanted nested annotation families - in particular, Section Heads.  You cannot delete them from the family browswer, so you have to go to Section Tags under the Additional Settings part of the Manage menu - and set the section head and tail families to None;  then you can purge them.  This makes a tiny difference to the family size, but if you do the job once in your family templates that difference will affect many subsequent families.