Where I Come From

In listening to someone, it can be valuable to know where they are coming from. If you are interested in where I am coming from, here it is. 

I am licensed as an architect, and have practiced several kinds of architecture (eg: residential, industrial, commercial as a project architect) and educational and institutional as a draftsman (yes, pencil, pen and ink on vellum). Before becoming and between stints as an architect, I worked for a specialties supply distributor (summers for 3 years), a modular and prefab homebuilder (2 years), residential remodeling tradesman (2 years), and precast concrete detailer (4 years using AutoCAD) and precast concrete project manager (8 years). I've been back at architecture using modeling software for the past 15 years. That's about as brief as I can be about my work history.

As for my current firm, I will say that modeling has made the design and documentation components of our work easier for us. More on that later. Since we have been at it for 15 years, for the applications we use, the modeling part of the learning curve is behind us. However, I can't say that the BIM learning curve is behind us, because 90% of our clientele (all small businesses and about half general contractors) has yet to wake up to the potential of BIM or any part of it. 

In fact, operating cost, let alone life cycle cost, is not even really on their radar. When it comes to design and contracting services, they want only what the statutes and regulations require. Whatever else we do is on our own dime or, if we have our wits about us, as extra services when these are requested. First cost rules. So I preface my comments with a disclaimer that I do not practice BIG BIM. I model. But I am concerned that when a client does ask for BIM services, I be in a position to advise them intelligently, and know what services I can provide, and what services I cannot.

Our projects are typically delivered by a kind of Design-Build process. In the typical setup, Building service (MEP) systems are designed and installed by subcontractors selected by the GC who is selected by the owner who negotiates a GMP with the GC based on preliminary drawings (and, if we have room in our budget) visualization models. As part of our basic fee, we are responsible for design of the shell, interior partitioning, and building code compliance, providing services (MEP) design-build contractors with background CAD files or paper base sheets, and publishing the paper document set for minor subcontractor bidding and jurisdiction review. Or fee includes hourly rates for negotiating regulatory issues with jurisdictions, and publishing any resulting revisions to the permit and construction documents.

So, that is where I am coming from.

Object Dilemmas

Modelers are faced with dilemmas like these (and others) many times in the course of developing a building model. While not the most frustrating or perplexing group of issues in modeling, they may be the ones that lead most often to the use of workarounds. I am asking questions here, not providing answers. The first question is
1. Why do software producers short-change their built-in object libraries and the documentation thereof?
2. You want to model a door without a frame (eg and overhead door), but there are no frameless door objects available in the libraries your software offers or those you normally use (It takes a while just to be sure it isn't there). You want it to be recognizable as a door to scheduling scripts in your application, to IFC translators, to the contractor's Quantity Survey application, to the owner's Facility Management application, to the jurisdiction's plan reviewer application, and to all kinds of analysis software tools. What do you do?
3. There is a product you want to incorporate in your model. The manufacturer has provided a pdf, a dwg and an rfa. You do not use Revit. What do you do?
4. Neither the built-in library of objects that came with your software, nor the four online sources of objects you use has the object you need. What do you do?
5. You find a file which claims to represent the door, window, or HVAC equipment you need in your model. It is in a format compatible with your software. It looks fine in 2D. It looks fine in 3D. You can change its color. It is even parametric, changing size and shape in response to selections made in its parameter settings. The following week, you set up a schedule to describe it and other similar elements and it does not show up, or it shows up, but some cells in your schedule for that unit are blank. Those parameters are not provided with fields for those data in the object settings options. What do you do?

Clearly, these problems can be solved by creating your own objects, writing your own scripts, or modifying ... if you know how; have spent the hours needed to make enough mistakes, and/or to get the training necessary, and have the time in your production schedule to take a detour through the object editing exercise, and a way to bill for the time you spend. These conditions are not usually met for most of the staff in most (smaller) architectural design offices. So, what do you do?

You fall back on 2d drafting, am I right?

Hello! Singular Repetition

This is the first post on littleBIM which aims to be broad in scope, short on pomp, and long on practicality.


Some tenets of Architectural documentation are put in whole new light as Building Information Modeling (BIM) becomes commonplace. One of those is the dictum "say it once, say it correctly, and say it in the right place in the documents."

In one sense, a given piece of information in a BI Model can be accessed from any number of views therein. While that datum is certainly lodged only once in a specific, unique location in the model data structure, it is likely to be expressed in a multitude ways, and expressed in output in a number of places. So, while we only say it once in one place, the model says it, and a model user hears it in many times and places, and there is no getting around that ... until we plot it on a sheet of paper. Then we can control it all again. Shall we take extraordinary measures to prevent access, or to avoid the expression of that information in more than one place to a model user? I don't imagine so.

Today, most of us still build from 2D paper documents even when we have designed in a virtual multi-dimensional environment. So it is the rectitude and consistency of the plots and printed specifications that is critical. It can be argued that it really doesn't matter how well crafted the model is, as long as the hardcopy is right. And in court, that is true. 

In some future post, I may deal with the downside of workarounds that look just fine in the plots, and the glories of that golden day when it will no longer be necessary to translate our 3D designs into 2D for presentation on paper, and when we can trust our software implicitly.

But the topic of today's post is the duplication of information (or its despised corollary: the internal contradiction of information). Among the most interesting of the kinds of model elements which will never be built are those which report information about modeled elements in alphanumeric characters. The most sophisticated of this class of elements is the Schedule, whether it shows information about door frames, door leaves, windows, footings, beams, or assemblies, but Dimensions are another, and Zone identifier stamps or labels are another. There should be no reason for the same information not to be reported more than once in the printed documents if it improves their usability. After all, it is the same information. Assuming that we have modeled carefully, that the reporting elements work properly, and that we are smart enough to use them properly, there is no chance of contradiction. If the duplication is not gratuitous, but functional, I suggest that it is a good thing, not a bad thing. 

Some examples: 

The length of a wall may be given from CL to CL on a floor plan. Is there a good reason not to close a dimension string between finished faces of those walls in an interior elevation of the room enclosed by those two walls? I imagine not.  

If I have defined two labels - one to count occupants for egress purposes, and another to count occupants for calculation of required parking or plumbing fixtures - is there a good reason that the same room area should not be displayed in both (or many) different labels displayed in several different views and presented in several places on output hardcopy? I imagine not. 

Both these situations seem to violate the opening dictum. Is it becoming a shibboleth?

P.S. - 

A person checking plots cannot know whether the ink on the paper represents model data, a workaround in the model, a 2D vector drawing in the model but not extracted from modeled elements, or an image with no connection to any model data. Drafters: Please do not abuse the opportunities this opens to set booby traps for others who may need to make sense of your model after you have finished with it.