29 June 2013

IFC, What is it good for?

"IFC, good God, y'all
What is it good for?
Absolutely nothing, say it, say it, say it
Oh IFC, is an enemy to all mankind
The thought of IFC blows my mind
IFC has caused unrest within the AEC community
Frustration, then dissatisfaction, who wants to fail?"

with apologies to EDWIN STARR

Looking through blog posts and discussion groups there seems to be a lot of dissatisfaction with IFC. Some samples:

"It can (if done properly) be used for a static as-built record Information, but even when used for this purpose validation of the data is critical."

"Data Loss IFC has a horrible habit of losing information or dropping data when exporting from its native format."

" IFC is that it doesn't currently support all the clever time saving parametric stuff that we expect from BIM components these days. IFC is all about the geometry and data and upon export it normally dumbs it down to just that."

" The biggest barrier in my opinion is that no matter how good IFC becomes, it will never be as good or have the functionality as the native BIM package it was created in. "

"It annoys me when I see new BIM users (most of the time without software experience) shouting about how we must all adopt IFC & openBIM now-today, because on the outside it looks like a perfect solution, when in fact its actually a load of work arounds."

So what is going on? We keep getting lectured by BIM evanglists about how wonderful IFC is. These same evanglists are busily lobbying governments and large corporations to mandate IFC deliverables. There seems to be a lot of claims about what IFC can do, but little on what it can't do. I don't put myself forward as an expert on IFC and welcome comments that prove me wrong, but I thought I would share my investigation into IFC.


I won't go into a lot of detail of what IFC is, but paraphrased from wikipedia:
"IFC is an object-based file format with a data model developed by buildingSMART to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open source and is an official International Standard ISO 16739:2013.
For more information look at the buildingSMART web site, and as an example of their view of what Revit users need to know.



One of the things many people don't seem to appreciate is that IFC (and by extension COBie) is an exchange format. It is not a common format, like open source formats (DOCX, JPEG, XVID, etc.), or common proprietary formats (DWG, PDF etc.)
IFC is designed to be a format that only exchanges data between other formats. When you import IFC into a software it gets converted into that software's format.
Software that can open IFC files directly are IFC viewers, they can't actually edit the IFC file.

It is a good idea, an agnostic data format.
But what it means is that there are two points of possible error creation - when the IFC is exported, and when it is imported.
With common formats there is only one - at import when using the software's format, or at export when using different software.
So although an exchange format like IFC may be theoretically more efficient across an industry, in practical terms for individuals it is not. To get a specific result it is easier (and quicker) to write one set of code in one software than to write two sets of code in two separate softwares.


IFC doesn't seem to capture all the functionality of BIM authoring softwares. For example it contains size dimensions, but doesn't know which geometric entities these dimensions control. So it can't transfer working parametric objects.
Effectively an IFC import creates static objects, no longer editable.
This behaviour perpetuates problems that BIM is supposed to overcome. If size parameters are exchanged and are editable, but the geometry doesn't change with those edits, there is potential for situations where the scheduled size of equipment doesn't match its geometric size. Which makes spatial planning and clash detection unreliable.


Although you can create an IFC file of a building that contains components, you can't create an IFC file of only one component. The file is effectively a building with one component in it.
I find this surprising. You would think an open format for distributing components would be high on the priority list.
There are a number of initiatives to create BIM component standards, like the UK NBS National BIM Library. But they have had to include Revit files due to the lack of functionality of IFC files.
That said, it should be entirely possible for a component IFC file schema to be created, and I believe buildingSMART is looking at this. See this presentation.
But currently IFC is not a suitable format for components.


IFC is pushed as an archival format. The argument being that the constant upgrades to proprietary software formats means any files retained now will be unreadable in the future. Whilst IFC, being a published standard, will always be readable.
But as explained above IFC is not a software format. It is an exchange format that requires other softwares to create and read it. Therefore it relies on proprietary softwares to maintain the ability to read older IFC formats. Which seems to me no different from relying on those proprietary softwares to maintain the ability to read their own formats. One could argue it is more likely they will do this for their own format than for an external format they derive no income from.
There is a mitigating factor though, the fact that IFC rarely gets updated means proprietary softwares don't have very many versions of IFC converters to maintain.
But the fact remains the problems of archival storage of digital data are NOT solved by using IFC.


IFC is pretty much useless for As-Built BIM that will be used as a resource for future changes to a building. As an exchange format IFC can't be directly edited. And most data that handles the original authoring software functionality has been lost in the exchange. So at best IFC can only be used as a static background in an authoring software with editing capability restricted to deleting parts.
Even if you import this static model there is the problem of loss of fidelity when an IFC file is imported into an authoring software. Without painstakingly checking every element it is not known whether everything from the IFC model has been replicated.
Then once the changes have been made in the authoring software, the export back to IFC is also problematic. If only part of the building has been changed how do you integrate that into the original IFC model?  If the whole building is exported back replacing the original IFC model how do you deal with the time lag that means differences in data content, or the problems that arise if the IFC model is linked to a third party database.


I have looked through the IFC and COBie descriptions, and I'm sure if I tried really hard I could understand it. But I don't want to try, I've got more important things to learn that are actually relevant to my area of expertise. I'm an architect, not a computer programmer. I'm sure most people in the AEC industry feel the same way.
Just look at what IFC stands for - Industry Foundation Classes. What does that even mean? (when I talk about IFC to a project team they ALWAYS get confused and think IFC is "Issued for Construction").
Does this really matter? IFC is a software standard, not a human process standard. In theory us users should be shielded from the inner workings of IFC by the software we use. But the reality is we end up having to delve into IFC because the softwares don't provide what is required for us to do our work. We are also getting owners with specific IFC deliverables, that describe these deliverables in IFC terms.


This issue is one I can't answer because I am not a computer programmer. All I can go on is what I read in discussions and blogs by people who know a lot more than I do. And I have to say what I have read is concerning, some of the issues seeming to be rather fundamental.
It seems some that have tried to use IFC are, if not exactly giving up, accepting IFC limitations.
Jon Mirtschin at GeometryGym has been using IFC as an exchange method to transfer data generated in Rhino by Grasshopper to BIM authoring softwares. I saw him speak at an IFC 4 launch, and what he does is amazing, and he is a strong IFC supporter. But he admitted he was having problems with IFC and has started to write code to import directly into Revit to overcome them. It seems you can only go so far with IFC.
On another front Bentley have announced they are developing an "RFA interpreter" that can import rfa files (Revit's component file format) into their BIM product.

But even given IFC's problems, and despite my scepticism, IFC is actually being used around the world.


Lets not throw out the baby with the bathwater. Underneath the practical limitations there is a fundamentally good idea. The fact is it is not, and never will be, the panacea it is claimed to be. But IFC must be useful for something.


Generally a BIM model used for analysis purposes doesn't require the whole model. Structural analysis only requires the structural components, thermal analysis only requires spaces, zones and envelope data. Some analysis software only requires parts of a building, or does the analysis one part at a time (e.g. floor by floor). Because IFC is an open format receivers of IFC files can break up them up without requiring the authoring software. Their analysis software may do it, or it can be done manually with third party software like simpleBIM at datacubist.com.
As IFC is usually simpler than the format of the authoring software so analysis softwares require less code to get the information they require, and it is easier for them to manipulate that data before importing it. This issue is becoming more important as cloud computing is taken up for analysis.
If all an analysis software does is the analysis then a static model like IFC is sufficient, but if you want to modify the model based on the results of the analysis IFC won't work for you.

So if you want to provide your model to some-one else for them to do an analysis IFC is a good idea, but if you want to do an analysis yourself that will result in changes to your model your authoring software is better.


A Facilities Management system does not need the ability to easily modify a building's geometry. The geometry is mainly there as a navigation tool for the data the system holds. In fact you don't want people to accidentally move fixed elements  around (which can happen in authoring softwares).
You also don't want an unnecessarily complex file format that can do more than you need.
So using IFC for FM makes sense. It is a simple format that has its geometry locked down. It also makes sense, in theory, for FM software houses to utilise IFC as they can then import data from multiple sources. I say in theory because they then become victim to the quality of IFC those sources create.
Of course if you need to make changes to the building's geometry, like add a door or change a wall, you will need to do that with a different software and try and integrate that change back into your IFC model. I'm not aware of a way to do this, but I suggest you make sure you have a robust, tested, process before committing to a reliance on IFC for FM.  


Current specialized clash detection software work by importing static models. They don't attempt, or have the capability to, alter imported geometry. Therefore IFC is a prime candidate for these types of software.
The ideal situation would be to have the ability to alter model geometry to over come clashes whilst doing the clash detection. But currently authoring softwares are not good enough at clash detection to make this practical. And then there is the issue of who makes the changes. Should the BIM Manager, who is not a structural engineer, have the ability to make changes to the structural model?

So at present, until authoring software improves and the responsibility problems are resolved, IFC is fine for clash detection and coordination.



IFC is not an authoring software format and in its current form is too limited to be really useful for making changes to an existing building.
However the pain associated with dealing with IFC could be alleviated by careful construction of the IFC model. For example by breaking it down into linked sub-models. If it is contemplated that IFC be used for As-built, as a minimum the process for updating building geometry should be established before hand-over to FM.


IFC's inability the keep the data authoring softwares rely on to make them useful means IFC is a bad choice for model exchange. If all you require is a static background IFC may be usable, but only if you are confident all objects survive the double transfer - firstly from the originating software and secondly into the receiving software.
The other problem is even if you get the IFC into your authoring software the control you have over it (visibility, display, data content) may be limited.


IFC simply doesn't have the ability to contain the parametric properties we expect from BIM components. Maybe one day it will, but for now don't waste your time.


When ever I bring up the shortcomings of IFC in public I get berated for not getting involved. It is open source, they say, anyone can contribute they say. But I'm an architect, I don't have the expertise to solve any of these problems. My contribution is limited to bringing up the short-comings of IFC. And I don't see how bringing up these issues in a closed forum could possibly be more effective than doing it publicly.

But should we practitioners support IFC? I believe we should. It is fundamentally a good idea.
Certainly volunteer to buildingSMART if you think you can contribute directly.
But if you want to contribute some of your time for free, my view is the most effective thing you can do is give IFC a try. Test it out, experiment with it.

And share you experiences. If things don't work bitch and complain, if they do heap praise on it.



viewer: http://www.solibri.com.au/other-products/solibri-model-viewer
optimizer: http://www.solibri.com.au/other-products/solibri-ifc-optimizer
List of IFC software:

Open source Revit to IFC Exporter:

IFC to Revit importers (both are optimized for services and/or structure):
GeometryGym: http://geometrygym.wikidot.com/downloads
ArchiCAD: http://www.graphisoft.com/downloads/interoperability.html

Tekla (optimized for structure):

Software like simpleBIM (http://datacubist.com) can clean up IFC files.

Geometry Gym:

NBS [UK] Revit Plug-in:

Bored with BIM?
Need a present for that special woman in your life?
The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, architecture and ... men.
Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

10 June 2013

Standards - Why don't we use them?

Its been a while since my last post, I took the opportunity of being in New Zealand for RTC Australasian to do some sight seeing. I have to also admit I was a bit "overBIMed". I found being immersed in a world solely of BIM, even for only a few days, taxing and a little demoralizing. But that's just me, my real love is architecture, not the technologies used to create it. It is certainly not a reflection on RTC events and how they are run. RTC are particularly great for those learning Revit and those wanting to improve their skills. I recommend it to those in the Americas and Europe where up coming RTC events are happening.

My talk on BIM execution plans, and my contribution to the Principle's Forum, didn't follow the "BIM is fantastic and problem free" line of most other contributors so I (deservedly) copped a bit of backlash.
One accusation was that I was being overly negative (some-one has to be), including not being supportive enough of open standards like IFC, COBie etc.

To be clear I think standards are a good idea, and more than likely necessary for BIM to become really useful. But a good idea is not enough. There is a bit of a circularity in standards - they are only useful if enough people use them, but to be used they must be capable of being useful, that is, practical.

The way BIM evangelists talk there is no good reason not to use standards. So why don't we? If they are so fantastic why do we need convincing?
I've tried to tease out some of the reasons that make us resistant to using standards.



We all try and be as efficient as possible. We work in a competitive field, there is no slack, no leisure time for processes that aren't immediately necessary.
So we try use the most efficient process for the task at hand. This is why processes are different on different projects. Each project has its own drivers and participants.
Using standards may be more efficient overall - over the entire project life - but not necessarily more efficient for each participant in doing what they need to do.


At best standards strive to be "average best practice". Some would say lowest common denominator. Within any standard, for a particular project, there will be some parts of that standard that are not applicable, and there will be things that the standard doesn't cover.
For this reason, in the real world, it is never possible to "fully" comply with a standard.


By their very nature standards are consensus documents. Even if many parties don't contribute, many parties have to approve and agree to its contents. This means they take a long time to appear, and are rarely updated as it takes so long. The latest version of IFC took 6 years to be published.


If you comply with something some-one has to check that it is happening. To use a technical drawing standard as an example, not only does some-one have to check a drawing communicates what it needs to, it also has to be checked it complies with the standard. And they are not the same. The fact a text note is in a font not in compliance with the standard doesn't mean it is not communicating what it needs to.


The danger in unquestioningly imposing standards is that those standards are treated as more real than the real world. Complying with the standard becomes more important than ensuring that the job at hand is achieved. To use the example above, drawings are only checked to see they comply with the technical drawing standard, not that they adequately communicate.
I've been called into meetings with contractors because they couldn't get the information they require from drawings that slavishly followed a drafting standard (AS1100) but didn't communicate the information they needed.

Looking back on these reasons, it occurs to me that the problem is not standards in themselves, but the way we approach standards.
If we treat them with absolute reverence, or conversely if we treat them as just another unquestioned burden, these problems will occur. But if we treat them as a resource, something useful in certain situations, they become a practical proposition.

Like I said above, standards are a good idea. There only a few, but powerful, reasons to use standards.



Standardizing the way things are done, and being familiar with that standardization, improves communication and comprehension. Having a standard for graphically showing door swings means everyone immediately knows which way a door opens.


Having an agreed way of doing something means everyone can spend less time working it out from first principles.


In principle you can use any method you want as long as you explain it. But explanations take extra effort. By following a standard you can just refer to that standard rather than include detailed legends and schedule notes.

These are generic reasons. But with computerization, and the wealth of data BIM produces, there are other reasons for using standards.


This may come as a surprise to you, but computers are not people. Computers are not good at using context to classify information, they require more precision (an example of which I explore in my post Which direction is Depth?).
If one digital system is going to communicate with another the information exchanged must be in a knowable form. The obvious way to achieve this across many different softwares is to impose some form of standard. There are many standards within the software industry that us users are (thankfully) unaware of. So when I talk about standards I mean ones that effect how we work, not how the software works.

Which leads to some interesting points.


Us users can only control what we do, we can't control what our software does. So when we are asked to provide IFC files, for example, all we can do is provide what the software produces. If it is inadequate there is nothing we can do (beyond employ programmers to work around the problems). No software vendor will  take responsibility for what their software produces so it puts us in an impossible situation.


And at what point are we, the users, responsible for ensuring adequate communication between different softwares? How much effort is reasonable to overcome what is in essence a problem outside our areas of expertise?
Is it reasonable to ask us to rename all our components (e.g. Revit families) just so the FM software can understand what it is being given?
Is it reasonable to ask us to use phasing (in Revit) in a way that helps the 4D software work? (we have just had this request on a project).

But when I get these requests I always wonder why. Why are we being burdened with extra work because of the inadequacies of software. Or is it the inadequacies of standards?

I'm not an expert on either, so I can't answer that. Perhaps it is a mixture of both. All I know is we are the bunnies caught in the spotlight.

But back to what we can control. Overall standards are a good idea, even ones to do with software. But use with caution. Treat them as guides, not commandments. Use them where they are useful, ignore them when they are not. And if following a standard creates more work, say so, don't fuel the myths peddled by the BIM evangelists.

In my next post I'll have closer look at the elephant in the room, IFC and it's sibling COBie.