Why use IFC?

Following my last detailed and highly technical post about model creation related to IFC, I received a comment on the blog piece from fellow Graphisoft ARCHICAD user and expert, Link Ellis from ArchiLINK. Link was seeking more of an overview to how IFC works for his clients. I think its fair to say that many people would like this, including me. Unfortunately I am not aware of any document that tackles this at present. It is something I have raised and we have discussed at buildingSMART UK Technical Group meetings. Hopefully this will become available in due course. In the meantime I will continue to share my IFC understanding (particularly related to ARCHICAD) and thoughts through this blog.

My last post was probably more useful if you understood the need and had begun to explore IFC, but in this post we will take a step back. Setting aside the general overview of how IFC works, I do think it is important to understand why all companies should begin to consider IFC in their workflows including those small companies who are yet to collaborate with others. This was Link’s other main query in his comments on my blog piece. It is almost irrelevant to understand how IFC works if you don’t understand why you need to even consider using it in the first place. So I will try and put down my thoughts on the “why?” here.

The need for neutral file formats

The need for neutral file formats is dependent on what software you need to exchange your models with. If you are working with someone using the same software then using a native file format makes sense. However, as BIM grows both in the UK and internationally it becomes inevitable that you are going to have to exchange a model with someone not using your brand of chosen software at some point in the future. Even where you can get the design team (architect, structural engineer and MEP engineer) using the same software you will inevitably need to collaborate with someone else in the supply chain using another solution. I’m not going to say that is not possible to deliver an entire BIM project with a single software companies solutions but I believe it will be increasingly rare.

Whilst a large number of consultants in the UK working on building projects have adopted Autodesk Revit as their chosen authoring tool (other solutions are of course available!), many civil engineering projects have utilised Bentley’s software solutions (Bentley solutions also cover buildings as well). At some point these two different solutions will need to interface, either now or in the future. Equally many steelwork sub-contractors have chosen to adopt Tekla Structures. These varying solutions immediately create the need for interoperability.

Of course as an ARCHICAD user (or indeed other authoring software users for Nemetschek Vectorworks, Allplan or DDS-CAD for example) we need to interface with these solutions as well. But this is only looking at software exchange between authoring platforms. Other solutions are predominantly more interested in the data, take for example costing software such as Exactal CostX or Causeway BIM Measure. Then eventually models need to talk to all manner of client CAFM systems. This is only a small selection of the BIM functions possible and the available solutions on the market but you can begin to see how many connections need to work.

So there are two simple solutions to this problem as I see it – plugins between each solution or a common format. Plugins are ok but in the long term they aren’t really sustainable given the plethora of both existing and emerging software. So the industry will benefit with the increased use of common BIM exchange formats. We had DWG for 2D so its a case of having the same for model and data exchange. This of course is where standard open industry formats like IFC come into play. I’ll concentrate on IFC for this blog but BCF and COBie also fall into the category of open industry BIM formats.

So if we begin to understand the problem with a vast array of solutions out there, then we need to understand what benefit these formats will bring to us as individual companies. In order to do this we need to understand our outputs. These vary depending on discipline. As architects and ARCHICAD users I will focus on our view of the world when it comes to IFC.

3D models

Building Information Modelling (BIM) is essentially all about the ‘I’ part and this is what separates it from simply working in 3D. Lots of people think they do BIM but there are lots of outputs you can produce directly from a 3D model without even tackling the ‘I’ part. If your not tackling the information, then ask yourself are you really doing BIM? (thats not a criticism, everybody is at different stages of their journey and I ask myself this every day but be honest about where you are). So outputs from a model could include drawings, visualisations, animations and 3D printed models and these can all be produced without the information part. They are of course part of a step towards BIM but they can lack true ‘intelligence’ and yet still produce useful outputs without strictly being called BIM.

There are odd exceptions to this rule. Even a 3D model can be used to generate data and intelligence. A piece of software like Sefaira is a case in point. This uses a 3D model to provide feedback on the model for environmental design. The intelligence is applied to initial 3D design geometry outside of the authoring tool. This can then be used to influence the original authored design. So there is intelligence here but not directly through the authoring tool. Sefaira qualifies as BIM but the authored model itself could still essentially be just 3D.

So with a model that has no data you can create an IFC file which is purely about geometry – see my previous post for what you need to do to achieve this. It will inevitably contain some data (more of this another day) but for now we can think of this just as geometry. So why bother? Well if you follow what was set out in my last blog you can begin to share your model with others. As a minimum others can open this in one of the many free IFC viewers (see our interoperability page for a list of some of these) or better still in their own authoring tools or other compatible software. ArchiCAD users might say we should use BIMx (a model viewer) and yes this is a way of issuing the model but IFC can be used in tandem and presents other benefits. BIMx is currently an end result and has its place but IFC offers more opportunities for others to take advantage of the work you have generated.

BIM is also about collaboration so being able to exchange models with other like minded consultants for coordination is a leap forward from just modelling for your own needs. They can open your models in their own software and you or others can combine (or what is known as federate) these models into other software such as Autodesk Navisworks, Solibri Model Checker, VICO or Tekla BIMsight (to name just a few solutions on the market). These can offer the ability to carry out clash detection (checking everything fits). All of these solutions provide support for IFC import. Straightaway you are into the world of collaboration and you’re really on your ‘BIM’ journey.

Federated Model White

Image: Key to modelling sharing between project participants and the ability to produce a single federated model is the ability for a variety of software solutions to all talk to each other.

Even if you don’t have anyone to collaborate with you can still look to take some benefit. For example, you could invest in software like Solibri Model Checker to check your model geometry against a set of rules (it can check data as well of course). This can automate processes to ensure your design meets certain criteria and check the integrity of your model. This ticks boxes when it comes to quality assurance and theoretically is an opportunity to reduce your insurance premiums.

Building information models

Beyond 3D models we begin to truly move into BIM. With BIM as opposed to just 3D, IFC really becomes increasingly powerful and really deliver what it was designed to do – exchange data. This data can be used by many parties, from consultants to contractors to clients depending on their need. I will talk more about the data that we can input/output from ARCHICAD in detail in subsequent posts. However, often what is overlooked is that the BIM part from an architect’s point of view is crudely split into 2.

First there is delivering BIM to produce the same outputs you had previously, but more efficiently. As an architect this would include outputs such as door schedules and window schedules. Secondly though you need to think beyond this and realise that the outputs grow because you need to consider all architectural elements not just those we traditionally have scheduled. This means information embedded into walls, ceilings, roofs and so on. Many people think architects are simply creating efficiency through BIM but for me the outputs begin to change as you collaborate more with others and they want to take data from all of the architectural building elements.

So looking at ‘part one’ of BIM you could produce this information in your own authoring tool, produce the output as a schedule (e.g. Excel or PDF for example) and then issue. Technically with ‘lonely BIM’ you don’t need to issue the model, it is merely the vehicle to deliver the outputs. Of course there is nothing to stop you issuing the model but some elements may not have data added. You will need to be clear what data others can use for their purposes. Much of this data can be created in ARCHICAD with ‘native’ ARCHICAD parameters (e.g. parameters for listing) so this is why many people don’t look at IFC. Within ARCHICAD – doors, windows, stairs and other objects contain this ‘native’ data.

Parameters for listing

Image: Native data in the form of ‘Parameters for listing’ for a Chair within Graphisoft ArchiCAD

Using IFC in an ARCHICAD ‘lonely BIM’ environment also allows you to interface with other IFC compatible software. For example, dRofus is a tool that can link to IFC models and create Room Data Sheets and FF&E Schedules along with other useful deliverables. Solutions like this begin to leverage the data that you have created and again add controls to ensure that the data created is correct.

With ‘part two’ your model has more data and the model very much becomes part of your deliverable and actually most of this ‘added’ data is only going to be in the model. You may choose to use the authoring tool to create schedules for checking purposes but this output may not necessarily be a contractual deliverable. Now with these ‘other’ elements requiring data, ARCHICAD tools such as the wall tool, slab tool, roof tool, beam tool, column tool, shell tool, morph tool don’t contain the same ‘native data’. They have some but not everything that is needed (again i’ll explain this in more depth another time). So here we begin to look at using IFC data.

Now we could continue to use ‘native data’ for ‘part one’ and use IFC data for ‘part two’ but this just adds more complexity. (Note: ‘native’ data can be exported in an IFC file but there are some additional things to consider with this route – i’ll cover this in another post). It also limits our ability to use all the tools and produce the required schedule output. Our solution is to add all our data into the IFC data fields. This creates consistency for all users and is also more straightforward in explaining to others our data outputs.

IFC parameters for listing

Image: The same data as the ‘native data’ but using IFC fields instead for a Chair in Graphisoft ARCHICAD (note: this is for illustrative purposes only – you wouldn’t do this straight match as some of these fields already exist in the IFC properties but it explains the point that any data can be created in IFC)

IFC parameter data only

Image: Another way of looking at the IFC data for the chair in Graphisoft ARCHICAD

One of the advantages of using IFC data is where you choose to use an object (such as door, stair, window or other object) that does not have ‘native data’ in the form of ‘parameters for listing’. See my earlier post entitled “Sketchup to IFC (and COBie) via ARCHICAD“. This means we don’t have to worry about GDL (ARCHICAD’s object format) object quality. We are actually creating our own dataset and can apply this to any geometry.

For me as an ArchiCAD user, BIM and IFC go hand in hand. What it boils down to is “Why do BIM?” and “Why use IFC?” are essentially the same thing. If you don’t ‘get’ BIM first then you probably won’t ‘get’ IFC. BIM is about collaboration and data and IFC is the format to allow that collaboration and data sharing but most importantly being platform independent. This means you should be able to work with any other IFC compatible tool of which there are many.

I’ve alluded to some of the benefits of an IFC approach in this post. But you still may be asking why IFC if you are only a small company?  Well its pretty simple, set your business up to grow. BIM should be on your roadmap even if you are small, and being small makes you more flexible. If you know what you’re aiming at then it is easier to get to where you want to be in the future. Think big and work back from there. Using IFC data instead of ‘native’ data is one way to think of creating an approach that is going to deliver other benefits in the future and provide your staff with a consistent approach from the outset. Setting up templates and approaches with IFC in mind really isn’t loads of extra work at the outset but it will be a lot more work trying to change (we all hate change!) and do this later. Once you hopefully get to a reasonable scale you can collaborate more and more and by the time you do, IFC model and data management as part of a wider approach to BIM will already be second nature.

Rob Jackson, Associate, Bond Bryan Architects

linkedinicon4

This post has been viewed 25878 times.

8 thoughts on “Why use IFC?

  1. Very nice article, I find it an excellent overview of the IFC issue, especially the explanation about geometry and properties parts.

    Sometimes I think that when people talk about the “I” in BIM they mostly refer to the “intelligent” parametric tools provided by their favorite software ( idea encouraged by the software maker ), which cannot be exported to IFC, which leads to the conclusion that IFC is bad. But if the software is really intelligent, these properties should be all it needs to recreate the intelligent object.

    Even so, IFC is a pretty complicated format, which certainly requires some work to use properly (many twitter accounts such as @berlotti or @openbim publish stuff from time to time about “best practices”), but no doubt it is worth it. Also worth mentioning, the IFC format specification is open, and not “owned” by a company, but published and maintained by an independent consortium…

    • The “I” in BIM relating to intelligence? I had not considered people mistook Information for intelligence, yet now I think of it, it clears up a lot of conversations that I did not follow .
      Parametric capabilities are great yet expensive to create and sometimes I wonder if the time taken to produce paramteric GDL models is as valuable as some may think. I have over 500 GDL manufacturers models on my library and not once have I had an Archicad user say “wow they are great, thanks for sharing” . Yet they were done by a true Archicad GDL genius.
      Everyone has a different perspective on BIM yet personally I consider the “information” part is the one that holds the most value. Not only for the builder also for the Architect, as builders will pay for a bill of quantities and on larger jobs they will pay big dollars.
      I run a construction company and got involved in the BIM side to reduce time with estimating, I have my own flavour of BIM outside of Archicad (not Revit or Bentley) yet enjoy the benefits from interacting with Archicad users.
      Collaboration is the key to great design and construction.
      Once again great post!

  2. Rob,

    Although ArchiCAD can now export all of the data from GDL listing parameters, I love the one workflow approach with your data entry into IFC. It not only provides a solution for all elements so you place data in the same place but it means that you can advise your data recipients that there is one PSET to look at to obtain the vital data.

    Nathan.

    • Hi Nathan,

      You are correct that GDL data can be exported in an IFC file. We found that there were two workflows with this – all data or selected data. Because we want to know what we are exporting then selected data would be preferential but I looked at the amount of effort to set this up and thought that IFC was a better workflow.

      Whilst the example I showed puts all the data into one property set this was more to illustrate that native data could be replicated (I noted this under the image). I would always use the standard property set fields where they exist and then supplement with additional property sets where additional data is required. This is primarily as much of our data in the UK will need to align with COBie so using custom property sets is not always an option.

      Rob

  3. Hi Rob

    Will all of the items ticked in the IFC manager be able to be included in the IFC file and read by all software? I thick the IFC viewer I have used seem too. But what about other authoring software.

    What software do you use for the federated model?
    Who maintains the federated model?
    Is it the model that the QS/contractor uses to price/tender?

    I have used IFC to give to contractors and consultants to view and have had 1 project where I 3D collaborated with a mechanical services consultant using Revit. One small issue I have is if there is a clash you notify the consultant exchange IFC model and update, but until the exchange happens the model is incorrect. More often that not you need to print out drawings before the correction happens. How do you handle this? I just turn the layer off.

    Thanks

    • Hi Jason,

      That’s a lot of questions! 😉

      Any piece of data included in an element will be exported in an IFC file. Whether these can be viewed by other software really depends on what software you are using to view them. Because there are so many types of data and so many pieces of software, it is almost impossible to say with any certainty that exchange is guaranteed. However, the best approach is to setup your own requirements and then test. With other authoring software you have to ask what data do you need to exchange. In my experience other consultants are primarily interested in the geometry rather than the data.

      Our models tend to get federated within Autodesk Navisworks and Solibri Model Checker. Federated models at present are largely being managed by contractors although this is something we are capable of.

      Models for pricing are one of our main drivers for developing models with reliable data. They aren’t yet forming part of tenders but this will increasingly be the case.

      In terms of model exchange this comes down to agreeing process and timing of delivery. I agree that timing of updates can be an issue but i think that the increased use of BCF in the industry may be a solution for faster updates by all consultants. My personal view would be to cloud up outstanding issues. As architects we always want ‘finished drawings’ but we should be willing to accept that often it is ‘work in progress’.

      Rob

  4. Another great post Rob, well done.

    You’ve covered about all the questions that newcomers need to know, and touched on some areas that will provide plenty of food for thought for people further along in their BIM journey. And in doing so you’ve put it all in perspective. I’m sure many lonely BIM users will start to see how to make friends (so to speak) and do ‘Big BIM’.

    Personally I’d like to discover how much of this is integrated into your office template and how deep it goes. Do you find it practicable to set up all of your favorites with IFC Properties, for example? And in future posts I hope you share your insights into how you set up and categorize your property sets, etc. And get your opinion on the reference model concept (even in a federated model workflow) vs. a round trip concept, where elements can be shared, edited and returned. But I can wait until your future posts!:-)

    Oh and your writing style is to be commended. You explain things that are easy for people of different levels to grasp, are unbiased, to the point, and there’s no sign of ego or self-promotion to spoil your posts. Just genuine good knowledge and experience, which is a refreshing change.

    Looking forward to more. Thanks again.

    Cheers,
    Link.

  5. Pingback: How to Add IFC Properties to any element in ArchiCAD

Leave a Reply

Your email address will not be published. Required fields are marked *