IFC model quality and audit

Import, check and measure the quality of an IFC model.

By Julian Bringold ·

Quick answer

An IFC model audit checks how the file is built before any project requirement: spatial structure, containment of objects in storeys, unique GlobalIds, typing, units and georeferencing. In SeveUp App, each model's "Health" tab gathers these checks and states whether each one rests on a buildingSMART rule or on a good practice.

An IFC model is only useful if it is complete, up to date and usable by the other parties. SeveUp App helps you check that: you import your files, a processing step analyzes them, and you follow their state from the queue to the result.

Import works model by model or in bulk. Each new version of a model becomes a revision: you keep the history and set, per project, how many revisions are kept. The oldest are archived, then deleted after 90 days.

Once models are processed, you can explore them in 3D, alone or federated with other models of the same project. Naming conventions, available depending on your plan, check file names at import and reject those that do not follow your rules.

At each step you know where processing stands: waiting, running, done or in error. The help center describes each of these states so you can decide what to do with a file.

This topic is for BIM managers, coordinators and quality leads who receive models from several teams and must make sure they are usable before sharing them.

What an IFC model audit checks

IFC (Industry Foundation Classes) is the open exchange format for BIM models maintained by buildingSMART and published as the ISO 16739 standard. The schema for version 4.3 is developed in the open, and its sources are on GitHub. An IFC file can open in a viewer and still be badly built.

A quality audit looks at the file itself, before any project requirement. Does the model declare a single project, a site, a building and storeys? Is every object attached to a storey, with a unique GlobalId? Are units, placement and georeferencing consistent, and do the standard property sets match their definition? These points can be checked on any model.

Requirement checking comes next. Whether walls carry their fire rating, or every room has a number, is the job of an IDS file, covered in the BIM requirements and IDS topic. buildingSMART also runs its own IFC validation service, useful for a schema conformance check on a single file.

Importing IFC models and tracking revisions

In SeveUp App, models are gathered on the "Models" page. The "Bulk import" button opens "Bulk import IFC models", which accepts .ifc and .ifczip files, one or several at a time. The import runs in three steps: "Files", "Names" then "Link", the last one being where you attach the models to a project and a folder.

A new version does not have to create a new model. If a file has the name of an existing model, the wizard shows "A model named "…" already exists" and offers "Add as a new version" or "Create a separate model". From a model's page, the "Upload revision" button does the same for a single file. Each revision then goes through three processing stages, "Conversion", "Dataset" and "Scene", whose progress is shown by "View pipeline".

Revisions pile up quickly. The "Revision retention" setting sets, for each project, the number of "Revisions to keep per model": beyond it, the oldest ones are archived, stay restorable for 90 days, then are permanently deleted. Without a setting, every revision is kept.

The model health check in SeveUp App

Every model has a "Health" tab. It gathers generic checks, without IDS requirements, grouped into categories: "File and units", "Spatial structure", "Element containment", "Identity", "Typing", "Placement and georeferencing", "Properties and quantities", "Materials", "Spaces" and "Systems and groups". Each check states whether it relies on a buildingSMART rule (normative) or on good practice (convention).

The check starts on its own a few minutes after the model is processed; for an older revision, it runs the following night. A file over 600 MB is not checked automatically, and the tab says so. An organisation administrator can request a new pass with "Run the check again".

The result fits in one sentence. "2 errors to fix before release", for example, followed by the checks at fault and a health score computed on applicable checks only. An error flags a normative rule that is not met, a warning a convention or good practice, and a check that does not apply is never counted as "0 issues". The list can be filtered by category or with "Issues only". For each faulty object, it gives the GlobalId, a "Copy" button and a "View in 3D" link that opens the viewer on that object.

Checking a model before release, step by step

The path below starts from a file received from a trade. The manage IFC models guide covers the import in detail, and the explore a model in 3D guide covers the viewer. The IFC viewer page sums up its uses, formats and limits.

  1. Open "Models", then "Bulk import". Drop the .ifc or .ifczip file and choose "Add as a new version" if it replaces an existing model.
  2. Follow processing with "View pipeline" until "Conversion", "Dataset" and "Scene" are "Done".
  3. Open the model's "Health" tab. Start with the errors, then review the warnings category by category.
  4. For a faulty object, click "View in 3D" to find it in the scene, or "Copy" to pass on its GlobalId.
  5. From "Home", the "Check a submission" task brings together the model health and the IDS requirement gaps. If an error or a gap remains, "Send back to the team" prepares a "Message to send to the team", to copy or send by email.
  6. To check how it fits with the other disciplines, open the folder's "3D views" tab and click "Create a 3D view".

Common mistakes in an IFC model

Orphan elements come first. An object the export did not attach to any storey drops out of level filters and skews quantities; the "No orphan element" check lists them. A "catch-all" storey holding almost the whole building is the same problem in another form.

Identifiers come next. Two objects sharing a GlobalId break everything that relies on it, from BCF issues to tracking an object from one revision to the next. The "Unique GlobalIds" check catches it. Too many objects exported as IfcBuildingElementProxy is another sign of a badly configured export, tracked by the "Reasonable share of proxies" check.

Position becomes a problem as soon as models are federated. A model placed far from the origin loses display precision. Several models of the same site must share the same base point (IfcSite), the same length unit, the same orientation and matching storey elevations; georeferencing through IfcMapConversion must be present in all of them or in none. The tooltip on the "Base point" column restates these rules.

On the property side, a custom set named with the Pset_ prefix passes itself off as a standard buildingSMART set, which is what the "No fake “Pset” prefix on a custom Pset" check targets. One last trap: processing shown as "Done" that produced nothing. A revision's "What the conversion actually produced" panel flags it.

Going further

The manage IFC models guide covers import, duplicates and upload errors; explore a model in 3D describes section cuts, colouring and measuring; configure revision retention explains archiving. A healthy model still has to be checked against the project's requirements, the subject of the BIM requirements and IDS topic. Defects found are then tracked as issues, see BCF and collaboration, and filing models by folder belongs to BIM project organisation.

Articles on this topic

Frequently asked questions

Which files can be imported into SeveUp App?
IFC models in .ifc or .ifczip format, one at a time or in batches with bulk import.
What happens to the old version when I upload a new revision?
It stays in the model's revision history. If the project has a retention setting, revisions beyond the number kept are archived, restorable for 90 days, then deleted. Without a setting, everything is kept.
What is the difference between the health check and an IDS check?
The health check verifies how the IFC file is built: spatial structure, containment, identity, typing, units, georeferencing. The IDS check verifies the information the project requires. The two complement each other.
When does the health check run?
Automatically, a few minutes after the model is processed, and the following night for an older revision. A file over 600 MB is not checked automatically.
Does a warning prevent releasing the model?
No. An error is a normative rule that is not met, a warning is a convention or good practice. In "Check a submission", only errors and IDS gaps trigger sending the model back to the team.
Can several models be shown together in 3D?
Yes. A folder's 3D view shows several models in a single scene without creating a new file: each model remains a separate file.
Are naming conventions available?
Depending on the plan. A naming convention validates model names on import and rejects incorrectly named files.

Audit your next IFC model

Create an account, import an .ifc file, then read its "Health" tab before releasing it.