Consistency is the key when working with IFC. Consistency in terms of how you approach your modelling (which may need slightly differing approaches to a regular “modelling for drawing production” method), consistency in the standards, templates and even the views you use, and most critically, consistency in the parameters you fill in and how they are exported to IFC. If you do things differently every time, your IFCs will be different every time.
First off, a quick outline of terminology: In Revit you use “parameters” to define values.
In IFC a “property” is exactly the same thing, an “attribute, quality, or characteristic of something”.
In IFC there are certain properties that always exist in every file and on every object. Examples include coordinate locations (IfcCartesianPoint), lengths (IfcLengthMeasure), the version of IFC used (FILE_SCHEMA) and so on. Most of the time, you don’t need to know any of this. Your IFC software uses these to build the model representation for you. Most of these will be shown somewhere in the interface.
In Revit, parameters belong to a “group”, such as Constraints or Materials and Finishes.
In IFC, a “property set” performs the same function as parameter group in Revit: a “collection of properties”. Most viewing tools display these property sets as tabs.
In IFC there are a series of pre-defined property sets and properties with specific naming conventions. They are always named PSet_something.
An example is:
PSet_DoorCommon = a collection of door properties common to all doors. This property set includes
FireRating to give the door’s fire rating.
IsExternal to identify whether the door is external (TRUE) or internal (FALSE)
FireExit to define if the door is a fire exit (TRUE or FALSE)
Other user-defined property sets and properties can be included as well, but these should always be named distinctly from the standard IFC property sets. This would include any other Revit parameter.
Typically property sets and properties are referred to using the PropertySet.Property syntax. E.g. PSet_DoorCommon.FireRating or Identity Data.Keynote.
Exporting Property Sets
When exporting IFC the settings control whether these additional property sets will be included. This is defined in the Revit IFC Export settings under the Modify setup … > Property Sets tab.
The first 5 tick boxes offer a simple “yes” or “no” to each group.
Export Revit property sets creates property sets in the IFC for all the Instance and Type parameters for exported elements. Each group will be created as a separate property set.
In the example above, the parameter Construction Type is empty so it is not exported to IFC.
Should Export Revit property sets be ticked? Yes. It is very helpful to be able to refer to the original parameters in the same structure as they are originally defined. You may not need them all, but as my old Granny used to say, “it’s better to have it and not need it, than need it and not have it.” Properties will add to the file size, but not to the same degree as over-modelled geometry.
Export IFC common property sets creates the standard IFC property sets expected of each element. Note that this will result in some parameters exporting to two different locations. Fire Rating exists twice in the images below.
Should Export IFC common property sets be ticked? Yes. These are standard IFC properties and should be included even if it means duplication of some data.
Export base quantities exports the geometric quantities of exported elements e.g. area, height, width.
Should Export base quantities be ticked? This depends on the reason for exporting the IFC, or what it will be used for. Geometry always exists in an IFC – it needs to so that the model can be correctly interpreted and displayed – but the standard quantities may not be displayed, or in certain cases the values may be calculated from the IFC geometry or deduced from other parameters. If you need to check any of these against the original Revit values, then yes, export the base quantities.
Export material property sets exports properties from the Revit material definitions.
This is a tough one to deal with as there are a lot of dependencies going on when you choose to export the material properties. To start with, certain MVDs (Model View Definitions) do not support these properties. Secondly, many viewers do not have a way of displaying these properties, as they are not direct properties of an element. In the example above, the properties are exported to the IFC but do not display:
(If you’re interested, this is because in this instance, the IfcExtendedMaterialProperties which uses the values shown is not referenced by any object. The Revit export does not associate it correctly.)
Should Export material property sets be ticked? No. Not unless you have a very exacting client, and even then you may be better off adding additional parameters, not material properties, to complete the required data.
Export schedules as property sets in addition to all the above options, this also creates a property set for each schedule in your Revit model, related only to the elements contained in the schedule.
Export only schedules containing IFC, PSet or Common in the title the secondary option limits this export to only schedules containing IFC, PSet or Common in the title (yes, you probably guessed that).
From the example above, with only the first option ticked, all the schedules will be exported.
With both options ticked, only the “IFCSchedule” will be exported.
Should Export schedules as property sets be ticked? No, not unless you need an exact copy of your schedules in IFC to find data.
Next time, exporting user defined property sets.