Recently at RTC / ArchiCON Australia I had an opportunity to discuss research and development we have been doing on authoring Building Information Models (BIM) for quantity take-off. While the project had started as step-by-step guide in getting data from our BIM platform, ARCHICAD, into Exactal’s take-off platform CostX, the discussion expanded into how to plan your modelling requirements. RTC/ArchiCON Australia offered a unique opportunity to discuss modelling requirements with attendees from the major BIM platforms and from disciplines spread across the industry. With Quantity Surveyors, Engineers, Architects and Contractors in the one venue the discussion was robust and in many cases circulated around reaching consensus on defining LOD in BIM.
Firstly, by defining LOD I don’t mean giving the term a definition, as that in itself opens up a minefield of arguments. Do we talk about Level of “Detail” or Level of “Development”? Are we focused on the role that geometry plays or should we be focused on non-geometric information? The UK, USA and AUS all approach the definition of the term differently. Personally I favour the definitions in the Level of Development Specifications (BIMForum, 2015) because of it’s easy to reference visual guide but at POWE Architects we are also starting to hybrid this to work with other classification systems. In my discussions with the Quantity Surveyors at RTC/ArchiCON I was more focused on how we define the requirement for LOD in our models and how our models can communicate that LOD back to the authors and users of model data.
As Dave McCool points out, the BIMForum LOD Specification stipulates that “LOD’s are not defined by design phases”. We can identify the LOD we wish to achieve for elements or classifications within a design phase but it is not appropriate to define an entire model as achieving a whole-of-model-LOD. At the end of Concept Design we may have achieved an LOD of 200 on some aspects of the walls, floors and roofs but aspects of the building’s lighting, HVAC and plumbing may not have even begun to be considered. There are even situations that arise where it is not appropriate to define LOD across an entire classification; for example in a renovation project the existing structure may predominantly need only be modelled to LOD100 with the exception being the structure along the renovation interface which would need to be considered right up to LOD300 early in the Design Development phase.
Of course we cannot define the LOD for every element in the BIM Execution Plan (BEP) simply because of the sheer magnitude of the number of elements. We must therefore generalise to a degree in the BEP with the communicated understanding that not every element in each classification will fit within the generalisation. We cannot afford to be loose to the extent that we fail to define the requirements for all elements but there needs to be rules, procedures and measures in place so that all members of the project team can understand and anticipate the actions of the rest of the team.
Throughout a project we deal with many stakeholders in the process. Many of these stakeholders are not Model Authors, they are Users of the Model Data. There are also 3rd party users of the model data who will fall outside of the scope of even the most thorough BIM Execution Plan.
Communicating LOD to parties that are not considered within the BIM Execution plan can be very difficult. How do you communicate the intent of your model data when you may have no communication with them other than the model data itself? The solution that we are currently exploring is to use the BIM data to speak for itself. By adding an IFC PSET for Level Of Development and giving my team control over manually updating the LOD field as they want the data in that element to be relied upon to a greater degree.
Many of today’s BIM authoring tools allow highly detailed geometry to be created very quickly. Just because the geometry shows detail shouldn’t infer that the author has intended that detail to be relied upon. Remember, under the BIMForum Specification the LOD defines the reliability of the data, it does not limit the detail that the author can choose to input. By stipulating the LOD as part of the element’s properties we can significantly reduce the risk or 3rd parties misinterpreting the intent of our model data.
The end game of all of this is to have reliable data shared reliably.
Insight by Matthew Johnson – Associate Director POWE Architects
Read more about Matthew
Any views or opinions presented in this article are solely those of the author and do not necessarily represent those of POWE Architects.