Practical application of IFC & COBie: Model Creation

“Criticism comes easier than craftsmanship” Zeuxis (approx. 400BC)

For those of you who don’t know me too well, I am somewhat obsessed with IFC, or at least obsessed with working out facts from fiction with IFC exchange. Simply stating “IFC doesn’t work, therefore I refuse to use it” is boring and fundamentally unhelpful. It’s like saying “my phone lost reception so I am never using a phone again”. It’s also too easy to believe certain software companies aren’t interested in improving their IFC implementation. Come on, we can all do better than that. Nothing is perfect and that includes all authoring tools without exception and I am not going to pretend IFC is perfect either, it is far from it. Yet I know that it is perfectly usable for our live projects.

However, much criticism is placed on the schema or software companies implementation of the schema. These are issues of course, yet there is a third equally important component of IFC exchange – user implementation. We, as users, must all learn to use IFC better as this will ultimately inform the development of IFC moving forward. But we (the industry) must play our part in improving our skills. Use of IFC is a craft and not a magic button. In a series of blog posts we aim to look at getting the best out of IFC, particularly from Graphisoft ARCHICAD. We will start with model creation.

The basics

When exchanging any file format it is important to understand the basics of what will affect file exchange. For example, exporting a file from Autodesk REVIT is different to how a file is exported from GRAPHISOFT ARCHICAD. Both tools are authoring tools but both have different ways of approaching IFC. (If you are looking specifically for IFC expertise with Autodesk Revit then you should look at Martijn de Riet’s blog – mdradvies, just my opinions).

So for IFC geometry exchange, as a very simplistic view: Revit is predominantly about export settings; ARCHICAD is about model creation and export settings. There are pro’s and con’s of both approaches. In this blog post we will focus specifically on the model creation within Graphisoft’s ArchiCAD but there are also some lessons here for authors using other model authoring platforms.

Note that this piece is largely focussed on reliable geometry exchange and we will look further at data exchange in subsequent blog pieces. Remember if we don’t have reliable geometry then the idea of exchanging any useful data goes straight out the window.

So in order to produce a model that is suitable for reliable export we need to consider 7 key settings whilst modelling in ArchiCAD. These are described below and these should be addressed by ArchiCAD users during the modelling phase before even considering export. With each setting we have added where solutions are available within ArchiCAD to automate the approach and thus ensure that potential issues are eliminated.

1. Geometry and Positioning

This one is pretty self explanatory. Geometry needs to be modelled correctly by the user. One key difference when it comes to BIM over 3D modelling is the need to model the elements as appropriate vehicles for carrying data. So for example with 3D modelling you could get away with modelling a table as four legs and a top. However with BIM, if the table is to be specified and supplied as a single product it must be modelled as a single object.

Some might say that where coordination is the only goal that this ‘rationalisation’ doesn’t really matter but it should be remembered that every element contains at least some core data and so this increases the file size if you model separate elements. Put simply: less elements = less data.

The geometry itself also needs to be placed in the correct location as information will be available in other software about its location in the model. Model location is critical if you hope to exchange models with other consultants. We won’t cover this in detail here but it is important that you understand that model location will play a key role in successful data exchange. This is probably the most important consideration when collaborating with others. Get this wrong and you have no hope of collaborating.

ARCHICAD Solution: User Defined – this is all about training and understanding. It requires discipline but this would be the same in any authoring software.

2. Surface colour

In ARCHICAD 17 (and above), we need to understand that there are now 2 types of material – ‘Building Material’ and ‘Override Surface Material’. Where we are only interested in geometry we are only really interested in the surface colour. However, the surface colour can be controlled in two ways. Ideally we should use the ‘Building Material’. This will provide us with data, a correct 2-dimensional cut fill and correct surface colour. We can if desired change the surface colour by using the ‘Override Surface Material’. So for example the ‘Building Material’ may be set as plaster but the surface colour could vary. What we mustn’t do is simply ‘Override Surface Material’ and forget about the ‘Building Material’. This will simply lead to confusion even where we are only exchanging geometry.

Screen Shot 2013-10-22 at 14.53.43

Image: Building Materials and Override Surface Material control the colour of exported geometry

Note: There is a little more to understanding surface colour using IFC exchange which again I will cover in another post.

ARCHICAD Solution: User Defined (can be partially automated using Favorites)

3. ID / Name

Now the ID is not strictly required for geometry exchange but equally we often see models criticised as being unreliable because of duplicated and missing IDs. For non-ARCHICAD users, it needs to be understood that this data is not fully automated and can be controlled by the user. If it is screwed up, it is user error, not an opportunity to blame IFC exchange.

For ARCHICAD users it should be noted that the ID field is also the ‘Name’ field in the IFC Manager. These are linked – place data in one, you are automatically placing data in the other. This field in IFC terms is the ‘IfcProduct.Name’ field, which is required and mapped to the ‘Name’ field in COBie’s Component spreadsheet. In COBie, each element must have a unique value. If you aren’t delivering data you don’t need to worry about the field however you should consider making the field generic. So for example, insert ‘WALL’ as the ID for all walls rather than having WALL-001, WALL-002 etc.

Take particular care with your ID’s where you amend an Element Classification – See Item 5 below. Favorites is a good way to eliminate the potential for error here. You can of course number every element (required for COBie) but you need to manage this data carefully. I will write a separate post on this at a later date. For most projects, we only assign Doors and Windows a unique ID as default. (note: we also have unique ‘names’ for Spaces but these do not use the ID/Name field)

ARCHICAD Solution: Favorites / Element ID Manager

4. Structural function

This is a fairly simple ARCHICAD setting but has the ability to cause havoc with IFC file exchange if you don’t understand it. The user has 3 options – ‘Undefined’, ‘Load-Bearing Element’ and ‘Non-Load-Bearing Element’. There are two ways to approach this setting. Ignore it completely or use it fully. The important thing is that there should be no half-way house otherwise you will almost certainly lose geometry when you start playing with the export settings. By default, ARCHICAD is set to ‘Undefined’. So if you are unsure how to use this piece of data then leave it well alone.

However, fully utilising the Structural Function allows more control over what you export. Structural Function may seem like an obvious setting but it is a little more complex than this. A studwork wall is typically not of course structural but switching off all the walls on export is going to be probably more confusing for the engineer. He/she will probably think the IFC is to blame.

I prefer to think of the Structural Function setting as “Do you want to send this to the Structural Engineer?”. This means that elements that you don’t need to send can be switched off. This reduces the amount of geometry (and of course related data) that needs to be exchanged. Good examples of this are doors and windows. The engineer only really needs the openings that doors and windows create but doesn’t need all the associated geometry and data. Setting these to ‘Non-Load-Bearing Elements’ means we can reduce the IFC file size sent to engineers.

Screen Shot 2013-10-22 at 14.54.01

Image: Structural Function

ARCHICAD Solution: Favorites

5. Element classification

ArchiCAD allows the user to classify elements component by component (note: Element classification is different to Classification (i.e. Uniclass, Omiclass etc)). So by default using the wall tool will classify the placed element as a wall. However, the user is in control of every ‘wall’ element they place and thus any of these elements can be classified as a different type of element. So whilst users think of the wall tool for just walls, they can in fact use this to model anything. Crucially however, they must consider how they then classify the element they want to place. Changing the classification also changes the available data to add to the element. Put simply all tools in ARCHICAD are just that – tools. However, with this flexibility comes responsibility. Ignoring these settings leads to inevitable issues with file exchange.

In Revit, element classification is controlled by a Category mapping table before exporting. So a Wall is mapped in the ‘IFC Class Name’ field at the point of export.

Screen Shot 2013-10-22 at 14.54.12

Image: Element Classification (the unexpanded list shows only architectural elements – choosing “More…” expands the list of available elements)

Note: Again there is a little more to Element Classification which i will talk about in (yet) another post.

ARCHICAD Solution: Favorites

6. Renovation status

This is another straightforward setting. The user has the choice of Existing, Demolished or New. Its basically what a Revit user would call Phasing and an ARCHICAD model can be exported so that the settings tally. I have many users tell me I am only modelling a new building so I am not interested in this setting. However, it is a piece of data and even new building’s need to be placed on an existing site!

Note: Take particular care when changing between a 2D and 3D window. The Renovation Status is not central and so the setting can change between the windows. One solution to avoiding this is to only use the View Map to navigate. This prevents accidentally putting elements on the wrong status.

One thing to note with the Renovation Status exchange is in order to get this to work correctly with Revit currently, the ArchiCAD plugin must be used for import.

Screen Shot 2013-10-22 at 14.54.30

Image: Renovation Status

ARCHICAD Solution: Renovation filter

7. Layers

This is one that Revit users often dismiss as they don’t use layers on a day-to-day basis within their tool. Yet when any model is exported, be it from Autodesk Revit, Graphisoft ARCHICAD, or other authoring package, an IFC file will contain layers. For the ARCHICAD user, again there is individual control for every element placed. Again the user has the responsibility of making sure the settings are correct when modelling. For Revit users during the modelling phase they don’t need to worry about the settings. However, when they export their models they need to select the correct layer mapping that will ensure elements will be placed on the correct layers. This is actually done within the DWG settings (or alternatively with a .INI file in the DGN settings). The layers can be configured in these settings and for us we want the elements to be placed onto the UK national standard BS 1192:2007 layers.

The agreed layer format for any project using IFC, DGN or DWG exchange should be documented in the BIM Execution Plan (BEP).


Image: Architectural layers within ARCHICAD (this shows an early implementation of BS 1192:2007 using Uniclass2 for classification with the now removed Work Results table)

ArchiCAD Solution: Favorites


So of the 7 key settings, most of them can be preset removing possible user error. Of course a user still has the freedom to amend these where project specifics dictate (and that’s a benefit of having user control) and as long as the user understands these settings then geometry exchange can be exchanged reliably. Remember, as I started with earlier, much is made of poor software implementation but there is just as much onus on the user to get things right. This blog piece aims to give you the knowledge to get it right, but this knowledge must ultimately be applied correctly in practice.

This blog piece has focussed on model creation but in subsequent blog pieces we will look at other practical applications of IFC and COBie including data creation and model export.

Rob Jackson, Associate, Bond Bryan Architects


10 thoughts on “Practical application of IFC & COBie: Model Creation

  1. First of all, thanks for this great post. This is what your average fledgling ArchiCAD user needs, something that cuts through all the BIM babble and starts to clear the path on how to actually do BIM.

    IFC is kind of our golden egg to outside BIM, yet so few people really know how to use it. In my experience, generally most are frightened by the acronym, if they’ve even heard of it. I wonder if you have or can direct people to a resource that illustrates the basic flow of information using IFC. And then help explain more ArchiCAD specific issues, like how and why people would use the IFC Manager and Translators, how element classifications work with schemas, a definitive (?) list of classifications, the reference model concept, etc.

    As keen as I am to delve into the pros and cons of naming wall IDs for internal take offs vs COBIE fields (let alone read your promised ArchiCAD>IFC>COBIE posts), discuss your use of renovation statuses for IFC export, etc, I think it would be hugely valuable for the general masses if someone could take a step back and explain the basics.

    As experts, we often lose sight of what other people don’t know. And I am by no means an expert when it comes to implementing IFC the way you do! I really hope you are able to shed more light IFC!


    • Hi Link,

      Thanks for taking the time to comment. I would respond as follows:

      Basics – Unfortunately I am not aware of anything that is currently available. This is something we have discussed at buildingSMART UK Technical Group meetings. It is needed but where I can I will try to explain some of this in future posts.

      Other detail – Most of your other requests I already planned to cover in future posts. There is a lot to get through and lots of cross over with different areas but hopefully each post is as clear as it can be. Even I don’t pretend to be an IFC expert. I probably understand more than most but I’m still learning as well so I will share what I do know.

      I appreciate sometimes I dive into detail and I’m afraid that’s my view of life. IFC is all about the detail. Equally I try and remember the audience has different levels of understanding. Striking a balance is always difficult.

      For my next post I will try and go back a step and explain some more of the “why bother with IFC?”.

      Hope that answers your question.


      • Thanks Rob

        I did not intend to criticize your style. Quite the opposite, so I hope no offence was taken.

        I train ArchiCAD users of all levels of skill, and I know that generally, apart from the bigger firms, most of them are too overwhelmed by IFC, and combined with a lack of general overview information, they are simply put off by it.

        I’d really like to see these barriers cut down. Once users get a general gist of how they can use IFC effectively, then they can be taught how to tweak the settings within ArchiCAD.

        I really look forward to more from you as there seems to be very few ArchiCAD users beating their way down this track and willing to share their insights.


        • Hi Link,

          Certainly no offence taken. Its useful to get some feedback. I’ve already started on trying to put together a response in another blog piece to try and answer your points.


  2. Rob,

    The timing of your post is perfect, I had planned to record an in office training video this morning on preparing to export IFC files and I saw this pop up. Might just point them in this direction instead.

    It is a great, simple explanation on how to get a good quality / basic data output of IFC from ArchiCAD. This information should help a less experienced user step up and have less fear in building their model with a few additional parameters and get a output from ArchiCAD that is more suitable for collaboration with others.

    You didn’t mention it in your post but I am sure that you would do the same thing, I audit, check all of the data is correct in the Interactive Scheduler prior to issuing an IFC, it is a quick way check everything is set right for export.

    Just one query, our data requirements are pretty simple as we use our models for design collaboration and don’t have a client data deliverable. Our staff that issue IFC files are trained in the processes you nominate above and adding this process is not really time consuming. How are you treating the additional data requirements in your office, I know you heavily rely on favourites, do only a few people manage this data at the favourite level and your general staff aren’t trained at that level, or are all staff fully aware of all of the data embedded in each element.


    • Hi Nathan,

      Thanks for taking time to comment. The post was really focussed on the minimum requirements for geometry exchange, of course some of this is in fact data, but I wanted to try and break it down into different subject related posts. I felt this was the easiest way to try and keep the audience (of all levels) engaged. IFC is a vast subject with overlap and tangents in many areas. Schedules of course is one and I will cover this in another post. But in short, yes we are using schedules to both input and check data.

      We are still working on pushing out much of the work our central BIM team are doing to projects on the ground. Almost everyone has had at least one session of training in how to create and manage data but much of this at the moment will only be for new projects started in the last few months. This will increase as new projects come online. Like you there is little client demand at present but most of this is being driven by contractors and others like cost consultants wanting to use our data. However we are setting up our approach to deliver to all parties as the BIM requirements grow on projects. Essentially we are setup to deliver a minimum level of information but this can be added to as required by project specific requirements.

      With regard to Favorites I will explain how we are tackling this in another post. This is something we have turned to relatively recently, although we played around with them in the past. But essentially there is a ‘full set’ of Favorites that can either be tweaked to suit or added to by the user. I think the knowledge in this area will grow as users use the approach more and more and they become more confident in setting up more of their own.


  3. Rob.

    Nice Post. It sets out the best starting point for the process IFC export (I wish you could have written about a year ago) :). I have managed to get to the same point by trial and error. My first export/import to Revit took 13 tries to get a model that had minimal errors in Revit. When there are issues with an import of an IFC file, I would advise users to go and see your consultant to actually see how they import into Revit (or other software) and what the final result is. You will learn a lot.

    On Element Classification, when a Wall is actually a Wall do you leave the setting on Archicad Type ?

    I will be interested to hear how your are handling Favourites. V15 & 16 I had a lot of them (probably too many) I tried to have an option for multiple types of objects, walls etc. Now with V17 I have stripped them way back to only 2 or 3 options per tool.

    • Hi Jason,

      Thanks for the comments. I’ve only just written this as I feel confident that this model creation process is robust. Like everything I’m sure others might be able to add some other suggestions but through our testing this is one part of the process that we are pretty clear about. I agree about the importing into Revit. We bought a license ourselves and have carried our hours and hours of tests. I appreciate not everyone has this luxury and in many ways this is the knowledge we have gained from those tests.

      Too many ArchiCAD users have a habit of blaming the receiving software, and of course there are some niggles (not that many really) but they forget that they have to build their models correctly in the first place to get good results. Other things also influence the end result and I will tackle these in further posts.

      I’m going to write another piece specifically on Element Classification but to answer your question, I have set a Wall as a Wall in our Favorites. GS would state that it should be ArchiCAD Type but this tends to confuse users.

      Again with Favorites I will try and put this in its own post. We are still feeling our way now that our latest template is out ‘live’ in the offices. I may change my mind, based on user feedback, on what is best but what I will say is that it currently varies by tool. Some have more than others at the moment.

    • Thanks Nando.

      Glad you liked the post. My only comment would be like any feature request to put this back to Autodesk. To me IFC functionality requests should be no different to any other functionality requests but in my experience many users don’t feedback their requests for IFC development or issues to the software companies. Software companies can only develop these requests and resolve issues if customers communicate it to them.


Leave a Reply

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

20 − 8 =