Sunday, August 25, 2013

LOD Reply: PracticalBIM

Over at the practicalBIM blog, Antony McPhee has provided a few very insightful posts about real world (ummm...practical) application of the levels of development (LOD) for modeling. His most recent post, "LOD, are we there yet?" raises some interesting questions that I'd like to address.

First let me share some background information. I am an active member of the LOD Specification work group. The establishment of the LOD Specification is just that - a specification. It is intended to be a baseline, or a minimum standard. Where there wasn't a clear methodology for modeling something to a particular level, we did not speculate on a single solution. Instead the Specification allows for additional customization to be appended to the baseline in a BIM Execution Plan.

Isn't BIM about data?

First topic Antony approaches is the notion of "non-graphic information" (as described in the AIA digital practice documents and the LOD Specification). Of course it's all about 'the I in BIM'... This is a known issue and despite the LOD Spec group working for over two years, we have barely scratched the surface in terms of standardizing which parameters or properties go with which levels of development. Luckily, we have the IFC schema and the Object Element Matrix (OEM) from the US Dept of Veterans Affairs (VA) to help us heading into the next version. (Refer to VA BIM requirements, and the OEM spreadsheet) We will be looking to incorporate some form of this type of required information matrix in the next version of the LOD Specification.

LOD 100

Oh...that one. I could write a book on this topic alone because the LOD Spec group spent so much time debating about this level. The initial assumption was that a system or component at 100 might not be modeled, but provided as 'non-graphic information' in a narrative or attached to other model elements. Wait...what? As an example, you might model a simple floor slab and assign a parameter for an allowance of structural framing per unit of area.

Another assumption was to utilize a massing model. This is something that most Revit users are familiar with, but could also be accomplished in SketchUp, Rhino, and so on. The first debate was whether to make a 'mass' it's own class of model elements like walls or floors. What does a mass at LOD300 look like?... End of that discussion. A mass is simply a medium to establish a level of development for some other element class.

After many weeks and months of deliberation, it was finally decided to keep it simple and maintain the relationship to the classification of system element. Think of it in terms of one step below LOD200 (generic placeholder). In a wall example, 100 would simply be a wall - not identified by type or material. At 200, you would at least distinguish between drywall and masonry, but not specific types.

Take a look at the final published version of the LOD Specification 2013 and you'll see the clearer definitions for LOD100.

What ISN'T in the BIM

Antony notes the absence of means to address elements in the model that are not to be referenced. That is good feedback for the LOD Spec group as we progress into the next version. It's always tricky to address something that isn't to be addressed...

Not necessarily in this section, but Antony asks about an object being "graphically represented." I think the intent is meant as "geometrically represented," but AIA might have been trying to be consistent with "graphic" versus "non-graphic." On the subject of using 2D symbols in the BIM, I will likely write another dedicated post on this topic based on my conversations with the BIM team at the US Army Corps of Engineers. In their Minimum Modeling Matrix (M3), they use LOD definitions along with a "grade." This grade allows an element to be either 2D or 3D. Read more about the M3 here.


This is a subtle difference from the topic above, but Antony asks how one addresses project content that is part of a deliverable package, but not in the model. This is a good question that was discussed quite often within the LOD Spec group. The simple answer starts with an equation:

Deliverables = Model + x

In this equation, x refers to anything else that might accompany a model being offered as a project deliverable. This might include drawings, specifications, napkin sketches, and so on. The LOD Specification addresses ONLY the "model" part of the equation - it does not serve as a guide to complete project deliverables in current work flows.

Now, if we are talking about certain building systems or components that are just not going to be modeled - for example, you might not be modeling furniture in your BIM - there are two ways to address this. One way is to simply not define an LOD in your project's BIM execution plan. The other is to devise some nomenclature to call out such omissions. Antony notes that "NM" (not modeled) could be used in the plan. Sounds like a reasonable solution to me.

Construction Documentation as a BIM Use

As I mentioned earlier, the LOD Spec is intended to be used as a measure of model reliability - if you will, the dictionary for the authors (modelers) and readers (recipients) of written works (models). It is assumed that BIM is currently being used throughout the industry to generate and deliver 2D construction documents, but the model itself is often not shared with estimators, builders, and so on. That is the focus of the LOD Spec.

The game plan for the LOD Spec group was much like the game Jeopardy - where you are given an answer and you have to guess the question. We did not want to explicitly state any BIM uses in the Specification; however, we did start with three uses common to the state of the industry today: 3D coordination, quantity takeoff, and on-site layout (see for definitions of these uses). The definitions of the levels were developed in order to fit these common use cases, but not restrict project teams to only three use cases.

Milestone Definitions

In the last section of Antony's post, he comments on the organization of milestones as columns versus rows in a table. He refers to another blog by Brian Renehan in a post titled "Developing LOD" in which an alternate method of documenting model milestones - with LOD's at the top - would allow greater flexibility with a project milestone schedule that is established on a weekly basis. If weekly milestones are used in reality, then Antony is correct in assuming that would not fit in a printable format, thus the need to flip the milestone table on its side. Personally, I've never seen such a detailed model progression schedule, and I don't think you would be able to get enough granularity out of the LOD definitions for that to be practically applied.

I am happy to get some commentary on the milestone aspect of LOD use from those in other countries. Please continue to contribute to this important discussion either in the blogosphere or on Twitter using #LODSpec.



  1. Just about every project I work on now has some sort of BIM deliverable beyond documentation. If it's a design / build project, the contractor is using the model for take offs and clash detection which actually DO require weekly uploads and updates to the LoD. The model delta from week to week is a way analyze the model for granular changes. We work with a lot of agencies (GSA, DOT, etc) who are all looking at the model as a means to help with asset management after building completion so the LoD will address model and non-model assets.

    the documentation is becoming only a part of the modeling process.The table we use looks very similar to the one you suggest above rather than the one presented by the AIA.

  2. One very interesting aspect we're dealing with these days is cost estimating through the use of models in various formats, especially DWFx exports. As Anthony alludes, it is important to know what's not included in the model, or what is included in the shared digital files that cannot be computed/quantified as is typically done with modeled elements. I think this exercise is pretty key because otherwise, cost estimating as the design progresses is just a bunch of smoke and has absolutely no value in my opinion.

    The estimator needs to fill in gaps for unknowns, but without knowing what's unknown, how can you do that effectively? The way I see it, you should start with a spec outline. At least take a stab at a detailed view of all the systems to be used in a project. Once the outline is complete (to be refined as the project develops), you can start looking at the LODs. Those systems will be in the project one way or another, so you have to establish how and where: Is it 3D only? 2D only? A combination? Specs only? This is extremely important information for the estimator to successfully fill in documentation gaps as drawings and specifications evolve. In general (blanket CYA clause!) all systems should be assumed to be described in 2D, 3D and specs. Anything that falls outside of this should be clearly identified. If it is shown graphically in 2D only, the estimator might be able to do a manual take-off through measurement. If the system is just described in specifications only (ex: very typical of fire protection systems for example), then the assumptions used to price that system need to be clearly stated by the estimator. For everything else that is modeled in a BIM authoring platform, you could quantify directly. The team obviously has to make sure they are modeling accurately. For example if a wall says it is fire-rated, it need to truly go to structure, otherwise you'll be underestimating. This is an example (walls) of where our current authoring tool (Revit) lets us down because the 3D modeled aspect and the way they display in 2D for documentation are not tied to each other, leaving the door wide open for inconsistencies and errors.

    In some projects, I refer to the model progression matrix as the "Building Element Matrix/Table" and clearly state that we have edited the list to the best of our abilities to make sure all major systems are called out (outline spec). Then we move on to each system and define the LOD and mark where redundancy might occur between models coming from different disciplines (ex: sructural walls might be duplicated in Structural and Architectural models; this gives the estimator a heads-up to make adjustments and avoid doubling up on quantities).

    Ultimately, buildings are desccribed in a combination of 3D, 2D and specifications. We're doing our best to be as transparent as possible so estimators can do their job well. Our projects are complex and even if we did a perfect job in communicating the type and quality of digital building data, true final built costs are bound to be off by some percentage.

  3. James,
    Thanks for your considered response to my post. I admire what you and the others have done with the LOD specification.
    Turning something airy-fairy into something real is a worthwhile but often thankless task.
    I appreciate BIMforum stuck to the [US]AIA LOD definitions, so any criticisms I have are certainly not directed at the LOD specification.

    But in the interests of robust debate I'll respond to your comments.

    Isn't BIM about Data
    My comments is not so much that there isn't a comprehensive specification for LOD data, (check out Australia's NatSPEC BIM Matrix for an example of that), it is about including something, anything, in the definitions about data.
    I wouldn't think it is that hard to come up with general descriptions of the type of data each LOD requires.
    LOD100 might be floor areas and floor volumes, LOD200 generic description and space allowances as x, y, z dimensions, LOD300 specific description and actual size, etc.

    In fact I don't know how anyone could come up with a useful specific list unless they had come to some understanding of what the general data requirements would be.

    Your insight into BIMforum's thinking is very helpful. It seems some of the thinking was around the idea that things other than building elements hold information (like Revit masses). And these shouldn't be in the LOD table because they are not in Uniformat. This would work if those other things weren't in the model, but sometimes they are, or more accurately, some are and some aren't.

    Maybe another way to view it is rather than a massing model consider an example of a rendered design model that is used for LOD100 BIM Uses. That could contain quite specific things for impact and effect. But how do you tell what are the architect's fantasy to sell the project, and what are realistic assumptions? This is actually quite common. The architect does a render to sell the project, then the QS is expected to cost it.

    But as I suspected - the definition is ultimately a cop out. Rather than define what LOD100 is, define what it is not; that is not LOD200.

    I don't have an easy answer, but there must be a better way to describe the intent of LOD100.

    What isn't in the BIM
    I think you have confused What isn't in the BIM with What isn't BIM as you really addressed this under that heading.

    I agree that LOD is only about the BIM model, not about other deliverables. But sometimes there will be things that an authorised BIM Use does need, but the team isn't going to put it in the BIM. There may be a number of reasons for this, from lack of skill to lack of money. But recipients of the BIM should be told this up front so they can establish a work around (and maybe charge for it).

    On the question of "graphical" I get your point. "Geometric" could mean data, where as "graphical" could never be data. But it still seems strange to me. I don't view my model as "graphical", that is a drawing. I view it as a 3D model, a physical representation of the the real world, not an image of it. What concerns me is it confuses people still using traditional methods. They actually use graphical representation, 2D drawings. Describing BIM as "graphical" makes it hard to get them to understand it is a different way of working. And harder to convince (some of) them that they really can't do BIM using CAD and spreadsheets.

    The UACE M3 is interesting, and I think they are doing some really valuable practical work. But I see their "grade" concept as an attempt to get their AEC teams to use BIM properly, easing them in by describing what form of deliverable they require. They are also dealing with situations where they may not require full BIM, or are working with people who have no hope of delivering it. I don't see it as a necessary part of using BIM, and will become superfluous once everyone starts using BIM software properly (and BIM software matures).

    . . . . to be continued

  4. continued . . . .

    What isn't BIM
    What isn't BIM are the things we put in our BIM model that SHOULDN'T be referenced for authorized BIM uses.
    An example is a retail zone in an office building foyer. It is an idea that may or may not go ahead, but the client still wants us to show it in our drawings.
    I don't think it is a complex question. I didn't say so in my blog post, but I would suggest using LOD000.

    This also ties in with the "creation of construction documentation" as an authorized BIM use. There may be things in our model we need to produce our drawings and schedules but are not suitable for other authorized BIM uses.

    Construction Documentation as BIM Use
    Again as I suspected. Assumptions being made by experts that non-experts may not pick up (we are all guilty of it).

    I appreciate BIMforum has recognised different BIM Uses may lead to different requirements, and applaud the clear statement of what BIM Uses have been taken into consideration for the LOD specification.
    But if Construction Documentation is a BIM Use it should be explicitly stated. It effects how the model is created and should be treated (as per my comment above).
    As an example of why this is important, I am involved in a project where the contractor, forced to use BIM by the owner, has decided there is no need for a connection between construction documents and the BIM model and is getting a separate BIM model made off-shore. I'm sure I don't have to go through the reasons why this is a bad idea.

    My question is would Brian's Renehan's layout be less restrictive, opening up LOD tables to wider use. The counter argument is would this layout be more confusing for simple cases. I agree it a matter of what people find practical.

    I am surprised at how little discussion our posts have generated. Maybe LOD is not being widely used so no-one is interested, maybe we are being too esoteric so nobody understands, or is it a conspiracy, the "standards mafia" have taken over and closed down discussion.

    But seriously, LOD will only work if we have some kind of consensus. I don't mean everyone agrees, just that everyone understands what it is and has some idea of how to use it.

  5. what everyone is missing is that LOD does not only reference the Model (read:Revit) but also any related documentation. I know the LOD committee focused on the actual modeling using Authoring software as the basis, but what about the Sketchup model with a spreadsheet of areas, materials specifications etc? What about an EdSpec for a school that defines requirements for the eventual school that then derives a Sketchup or 2D CAD series of documents. Is this not what LOD 100 is really for?
    I agree with James that the specification is just that, a guideline that shows us where to draw the line +/- for each of our elements and systems and allows teams to associate certain models and documents with LOD and allows outside people to have a certain level of trust in that element.

    We do use custom parameters in our LOD 100 and then export those to Spreadsheets or DB and compare to programming numbers. We often estimate based on SF parameters assigned to the objects etc. Sometimes we use 3D modeling software rather than BIM and assign the data at the back end if that makes us more productive.

    So when planning your LOD specification keep in mind non Revit elements like specifications tables and cut sheets that need to be addressed in your MOD. At LOD300 construction documents can be addressed as well, though I do not consider that a BIM use but rather a product of the BIM like specifications. Since we are currently relying on the CD's it becomes part in whole of the BIM model rather than a separate task like Estimating. That being said I would not disqualify a PxP showing CD as a BIM use

    Many great points and its good people are using and discussing this topic or nothing good will ever come of it.