Tuesday, October 01, 2013

UK Commentary on LOD

I stumbled upon another excellent commentary on Level of Development (LOD) from Stephen Hamil (@StephenHamilNBS) from NBS in the United Kingdom. On his blog, Construction Code, he writes about the differences and similarities between the LOD Specification and various developments such as PAS (Publically available standard) 1192-2:2013, which defines levels of model detail (LOD) and levels of model information (LOI); as well as the RIBA Plan of Work.

Take a visit to Construction Code and let me know what you think.

Wednesday, September 04, 2013

LOD Spec: Do I have to model in progression?

Over the course of the first two years of development before the first release of the LOD Specification for BIM in 2013, the work group thoroughly discussed many topics related to the real world use of the levels of development. One such extended discussion focused on how architects or engineers might develop their model data through the various stages of design while adhering to a model element table using the standard LOD’s.

The initial assumption is to think of LOD as ‘level of detail;’ therefore, you might think you are required to model with a generic component first, and then swap it for a more detailed component later in the design phase. While this approach seems logical in accordance with much of the imagery you’ll see in the LOD Specification, it’s not how most of us work.

The correct way to think about this progression is in terms of the RELIABILITY of the information in your model. For example, you might start a project with your company’s model template that has all the standard wall types defined. You might progress through concept or schematic design using an assortment of these standard wall types, but the overall layout and scope of interior partitions is still in flux. In this case, you would define Interior Partitions to be at LOD 200 in the early stages of design, and then specify LOD 300 for the latter stages. How can this work if you’re using the same wall types through all stages?

The LOD 200 definition in the LOD Specification for Interior Partitions includes the definition: “Generic wall objects separated by type of material (e.g. gypsum board vs. masonry).”

This definition can serve as either a guide to the model element author (architect) to model to the minimum specification – or, it can serve as the definition of reliability for a recipient and end user of the model, such as an estimator. An end user may receive a model with highly detailed wall types, but because it is contained in an interim deliverable and the model element table established Interior Partitions to be at LOD 200, the recipient can only use the model data up to the level at which the partitions can be distinguished by type of material. The more detailed data is there – but it cannot be relied on just yet.

Here’s another example – in another blog post from Practical BIM, Antony McPhee uses an illustration from the AEC (UK) BIM Protocol in which a chair is shown at varying levels of detail:


Notice that the reliable properties are shown in red. Now, what if your practice only has the chair model as depicted under Component Grade G3? Can you put that component in your model if Moveable Furnishings was initially specified to be LOD 200 (the equivalent of G1 in the above image)? The answer here is YES. You can put the highly detailed chair element in your project model, but the project design has only been developed to a conceptual level at LOD 200. Therefore, even though it looks like a finished, rendered product, it can only be considered as a generic office chair.

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 BIM.psu.edu 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.


Monday, May 13, 2013

LOD Specification is Here!

After two years of dedication and hard work, the first draft of the BIM Level of Development (LOD) Specification is finally available for public comment. The work group responsible for this important document is a joint task force consisting of members of the AIA and the AGC of America’s BIMForum.

Cam_LOD200-100 Cam_LOD200 Cam_LOD300

You might be asking, ‘what is an LOD Specification and why do I need one?’ The AIA’s digital practice documents defines 5 fundamental levels of model development, but offers only general definitions of what each level means. I offered some explanation of these in an older blog post.

This new document offers more detailed definitions of how model authors must create virtual components in order to satisfy the requisite reliability. Building upon the AIA’s original LOD definitions, the LOD Specification can be seen as a companion document – much the same way as a dictionary can be a companion to both an author and a reader.

The public comment period will be completed by early June 2013, but the work group will continue to revise the LOD Specification and publish it on an annual basis. Go to bimforum.org/lod to download your free copy today. I’ll provide more feedback and commentary in future posts.

Wednesday, April 10, 2013

Spring BIMForum Registration

The next AGC BIMForum event is rapidly approaching and this one should be quite interesting. Through the years, each BIMForum event has offered a theme within which all the presentations would focus. The theme for the April 2013 event is “The Human Side of BIM” and will focus on specific topics such as firm culture, change management, training, and motivation. Also adding to the human dynamic at this event will be the method of content delivery – Pecha Kucha. That’s right, all presentations will be grouped into common themes and delivered in 20 slides x 20 seconds format. Immediately following a segment of Pecha Kucha presentations, the speakers will remain on stage for extended question + answer periods. Should be fun! (I’m hosting the Training theme)


The event is on April 24-25 in Miami, FL at the Hilton Miami Downtown. There’s still time to register at http://bimforum.org/events/65/miami-bimforum/. I hope to see you there.

Friday, February 15, 2013

Time for a Revit Revolution

Have you heard the news?! Autodesk has a new app to help you model monsters! (Cost: $2 introductory pricing) It seems pretty obvious these days that big A's attention has shifted away from core BIM tools and towards mobile app development.
They are very proud to tout over 12 million professional customers, and in a recent Forbes article, “Autodesk’s Brilliant Customer Strategy” - they claim a new concept for development:
“Autodesk releases its new products first to consumers, thus turning the product vetting process upside down. Consumers pay less but they expect more. They can be far from polite or patient, and will only tolerate very short learning times—and few bugs—in new, untried products.”
Sure, Autodesk has developed some interesting mobile apps for our industry such as BIM 360 and FormIt, but lets take a look at their main BIM platform – Revit (Cost: ~$6,000 – $13,000).
When Revit was introduced to the market around 2000, it was ground breaking. Never before did the architecture industry have a database-driven, parametric modeling tool that was relatively easy to use. In the first few years of existence, Revit Technology Corp made vast improvements directly related to customer feedback sessions they would host annually, right after they'd have a major version release.
Then Autodesk took notice and acquired Revit in April 2002 for $133 million dollars. Since then, it seems there really haven't been the kind of innovative improvements we saw in the pre-acquisition years. Granted, those years were really about taking a brand new platform and getting it up to speed for the larger market of AEC users, but it seemed like the trajectory for innovation was much more steep than it has been in the years since.
The Revit development team often uses the term "fit and finish" referring to commands, tools, and features they initiated, but really haven't improved to work the way they really should. Take the fairly recent addition of the Parts functionality. This feature was intended to allow builders to take a design model at consists of singular assemblies such as walls, floors, and roofs and break them down into individual components (finish, substrate, structure, ...) for more accurate phase scheduling, estimating, and so on. Great! So, the builders can link in the architectural model and...uh, no. It doesn't work on linked models. Really? [CORRECTION: You can create parts from linked models in Revit 2013, just use the Tab key to select a model element within the linked file and the Create Parts button will become active.]
Allow me to review some specific issues my industry colleagues and I have been asking for over the past few years – a few of the larger ‘fit and finish’ issues that have yet to be resolved in my opinion:
  • Faster UI - While I believe Revit still has the lowest learning curve of all the BIM software on the market today, it's user interface still seems quite slow. Ever since the ‘drunken leprechaun’ debacle with the 2010 release of the new ribbon interface, it just seems that I'm always waiting multiple seconds for the ribbon and command buttons to react - even with a blank project file open. As a customer paying $6,000 and up, I would expect the basic software to function crisply and cleanly. As the Forbes article quotes about the app users, “Consumers pay less, but they expect more.” So, should the inverse be true…that we (I guess we’re not really ‘consumers’…) pay more, therefore, we should expect less?
  • Handle larger projects - This is another area in which Autodesk says that performance is always their top priority. They have made moderate strides in improving performance of large projects, but no real game-changers. They have improved the functionality and workflow for linking models, but certain quirks still remain such as walls not joining between linked projects, and it's still a pain in the butt to manage view references between linked projects.
  • Schedule templates - Here's one I was hoping would happen sooner because of the functionality Revit has for MEP related to panel schedules. The scenario is for buildings in which you need to create a series of schedules that are usually based on each level. For example, if you need to generate an area schedule for each level to include on code analysis sheets. To do this in Revit, you need to create a unique schedule for EVERY level - essentially using a filter to show only Level 1, Level 2, Level 3, and so on. Why can't we create one template schedule (kind of like a Keynote Legend...hint, hint) that is then placed on a sheet and will report only the areas visible on that sheet. Could be a huge time saver for firms working on mid-rise and high-rise buildings...but alas we must trudge ahead with the same functionality we've had since 2004.
  • Better custom/complex modeling - We've seen some interesting developments get infused into Revit related to their conceptual design environment, but there are still some annoying gaps that prevent truly complex forms from being developed through to construction documentation and fabrication. Why can't solids automatically join and heal? Why does a complex curtain wall system need to be created as a mass and then be inserted into the project? I'm simplifying a complex discussion, but I think this workflow could be vastly improved.
These are just a few areas where I feel Revit could be improved, but they have been at the top of my wish list for years. Perhaps it is time for Autodesk to let Revit go to a company who cares about true innovation for the users who are actually designing, constructing and managing buildings. I'm pretty confident we'll never see "Bentley Revit" or "Graphisoft Revit" - but at one point I was inspired by the possibility of "Google Revit." Given the latest trends, maybe the next idea will sound something like "Trimble Revit." All I'm saying is that it's about time a once innovative platform is returned to the status of hands-down game-changer.