#42 – Model delivery and IFC…
Photograph by Jaime Flores from Pexels.
More often than not, the model deliverable for a ‘BIM project’ is IFC. As the platform-neutral schema that it is, it makes good sense that IFC is required, but does the client really know what that means? Does the client understand what information they are getting and, more to the point, what information they are missing?
I’m happy to be the first in line to claim a dislike for IFC. I completely understand the need for an industry recognised neutral file format but as with any ‘one size fits all’ solution, it never fits all very well; in my experience, one size fits all…most nothing. Every piece of software produces it differently, every user creates it differently (with varying success) and every platform seems to read it differently too. As a result, the information exported to IFC tends to be incredibly unreliable and almost always lacking the finer detail found in the native platform from which it came. Some platforms produce IFC rather well, some users can produce it well too, but on the whole it’s inconsistent at best. Revit, as the industry leading information modelling platform, is actually terrible at producing it from the standard out-of-the-box setup; the author must do an incredible amount of work to produce a useful IFC file, something that everyone continues to do differently.
Even in a parallel universe where we can all consistently produce fantastic IFC’s, it still cannot be the only deliverable. IFC production is a one-way street, it’s export only. I have worked on several projects now where the client’s documentation states that IFC is the only deliverable format. YOU NEED THE NATIVE FILES – I cannot emphasise this enough.
As we progress, slowly, with BIMs and AIMs we work towards having real ‘digital twins’ for our built environment. A real digital twin has to be managed; it has to remain up to date. As a client, have you understood and made provisions for this to take place? If you rename a room, move a wall, plan an extension, change a pump or block up a doorway your ‘digital twin’ must also undergo these very same changes. Maintaining such a model is an ongoing process, ideally an in-house one. Who will do this? And, perhaps more importantly, how will they do it? It won’t be done in the IFC, that much is certain.
Only the native modelling platform, utilising the native file format, can be used for such works. Consider an IFC as the PDF of the BIM world. It’s fixed. Flat. Not strictly editable. Nothing more than a photograph of the real thing. With an IFC alone you will not have the ability to make changes and maintain that valuable digital information. The building may change, but the ‘photograph’ will certainly not change with it. There’s a wealth of information and functionality that does not exist within an IFC and that makes the original, native models so much more valuable. So, why are they so often overlooked? Why are clients not crying out to receive this information? Why are these model files not being subjected to the same level of scrutiny as the IFC outputs?
These irreplaceable sources of information are being routinely disregarded; it has to stop. On the other side of the contractual fence, design teams and contractors must enforce the value of the native models with the client teams. Rather than shying away and simply following an EIR, speak up. Demonstrate the value of the information, don’t simply cast it aside to avoid another deliverable. If we are to continue our development with digital asset management, we have to collectively understand the importance of the original, raw dataset. If clients start to request this information it could have a truly positive effect further up the line too, ensuring model authors get their act together early on. We could see improvements to the standard of information models, rather than a sole focus on slinging drawings out of the door and fluffing half-presentable IFC’s at the end. There are benefits to be had all round, but first we must appreciate that there is more value in the native model files than there could possibly be in any model output. These models matter, and all authors know it. They must be a documented requirement, they must follow a standard and they must be part of any deliverable.
Mr. Smith
smith@dbe.careers
You may also like
