“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.
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.
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.
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.
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.
Image: Renovation Status
ARCHICAD Solution: Renovation filter
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