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.

Revit 2015 Shared Parameter Tool Tips

Isn't it great that you can add tool tips to parameters in the family editor?  It is a nice new feature that should help us to manage all those cryptic parameter names.

Shared Parameters

You can also add tool tips to Shared Parameters.  But, you can only add them at the time of creation of the shared parameter - in the Shared Parameter edit dialog box (not in the family parameter dialog box).

  

Click on the Edit Tooltip button and then add your description

Once you have created the Shared Parameter, you cannot modify the tooltip - try clicking on the Properties button:

It shows the tooltip grayed out, and the Edit Tooltip button has gone.

Project & Family Parameters

In the project or family editor, when you try to add a new Shared Parameter, it lets you do so, but only shows the tooltip that you have already created (if you did so)

 If you choose a Shared Parameter that does not have a tooltip, then it displays a tooltip "Shared Parameter"

If you create a Project Parameter or Family Parameter, then it lets you create and modify the tooltip at any time later.

Summary

You cannot add Shared Parameter tooltips later, and you cannot modify the tooltip later.  That means you have to get it right first time.
You cannot edit the shared parameter file externally either - I tried it even though every bit of Revit advice tells you never to do that.

What a shame!  This means that we cannot retroactively make use of this new feature where we already have large Shared Parameter files set up.  It also means that anyone who has set up a standard SP file cannot make use of the feature (eg. ANZRS).

What this also means is that your Shared Parameter tooltips must be very specific because you cannot add tooltips when you use a shared parameter in the family editor (or project).  For example, if you create a SP called "Width_Two" then you have to define its tooltip at creation, not when it is applied to a family.  You might have an L-shaped object where Width_Two means the width of the short leg.  You might also have a double-panel door where Width_Two could be the width of the smaller panel.  That would mean you could not create SPs for multiple uses on different categories or situations (maybe a good thing?).

If I am wrong about this, or anyone knows how to get around it, I'd love to hear from someone.

Other new Parameter features in v2015