Persistant print-ready files from a BIM environment

Split the Data:Two are better than one.

Musings on massive (def: >100 mb) BIM datasets and a strategy for attribute seek optimization.

In working with a massive dataset on Revit (4 180+mb files, 1 120+mb, and 1 80+mb structural file, compressed), I have had the opportunity to observe the impacts to productivity and inefficiency of attributal seeking in the context of a large (+40 person) team.

Not good.

5+ minute load times. Multi-minute lag on certain commands. View load times. Save times. Reload latest. All of these add up to both actual and perceived inefficiencies in a BIM workflow. While the central database model offers many benefits, the question is how to improve on this?

While undergoing an experiment on a Linux CAVE system, I had the opportunity to work with a researcher writing his own modelling application. Our dataset was a +1gig ASCII file, and in doing manual edits on the dataset (ironically, on a homemade text editor), I had the opportunity to witness a search algorithm that was able to break the data into small batch sets, resulting in a seek time faster than a standard unix word count algorithm.

So, if it is possible to subdivide and partition the dataset in a way that allows for localized seeking, is it possible to modularize the data in a way that begins to prioritize a more efficient user experience?

This is an engineering question. Similar to current battery research, as batteries maxed out their golden ratio of weight to charge hold times, engineers have now had to begin studying ways to separate battery usage into a more efficient division based on the tasks that are being asked of it in order to extend lifespans while decreasing weight. If this same strategy is employed on a dataset, is it possible to separate graphic information from quick access from deep access data?

IE: Splitting apart the data when generated into clusters so as I access views, that information is both optimized in a location to speed graphic population and redraw on the GPU, as well as intelligent streaming caching to take away the generation lag, but not bogging it down anywhere else in the dataset? This could also allow for a separation of types of data, from representation vs. attributes, in a way that would allow a structural package to optimize data it is loading differently than an MEP package differently than an architectural package.

Combined in a cloud scenario, an optimized database manager can be loaded an run in parallel to the BIM app. The dangerous side of this would allow current modeling only applications such as SketchUp to, in parallel, develop an attribute database system that plugs into their software, giving them an instant competitive entry to the game.

This is what keeps life interesting. Carry on, diisssmissed!

Misusing made up words...

Oh words,  you silly silly things you...

After a 2 1/2 hour dialogue this week involving the terminology BIM, we have reached a point where it is as generic as saying CAD or model or ice cream (you gelato people know what I mean...). 

Why, you ask? 

Theoretical Rant:: start::

BIM originally was a push towards a dynamic building model,  which was a resolution of the traditional issues with 2-dimensional documents that were not linked to elevations, sections, etc. Moving into a 3-dimensional environment 10-15 years ago, architects began utilizing 3D for visualization, unconnected models that were detached from the document set.  As we matured, and CADD marketing intervened, we came to realize that we needed architectural models that were the basis of our design, and 2D 'views' dynamically derived in real-time from said model(s).

This, depending on which marketing ploy you conceded to, become Object-oriented modelling or BIM. Throw in some intelligent databasing for scheduling, and you have the basis for what Bentley, Autodesk, Archicad, and others are marketing as BIM today. 

That's great. 

But today the terminology is changing, as we are working dynamically outside the bounds of the architects' offices. Engineers, contractors, and fabricators, are all entering into the 3D arena. One model is not the case anymore, as you have system models that overlay from the EOR and DC trades. Simulation, analytical, cost tracking, sequencing, coordination, and E&O models all exist. BIM has become watered down with all of these.

And worse.

Lawyers are entering into the fray. AIA, AGC, and owners are all trying to interpret this landscape, and without a clear lexicon, this will only create greater confusion.

Where will this go? Hopefully a clean restating of terms. BIM needs to go away, as it is beyond recovery now. We need to look to the future, or even get to where things are today. This includes moving beyond the marketing brochure. This includes a clear definition of activities, who is doing what, and the processes that extend all the way through the lifespan of the model.  

Without this ground, we will not be able to move beyond the developers, able to control and shape the tools and methodologies on our terms.

::end::Theoretical Rant

And ice cream is egg based. Gelato is not ice cream. Sorbet is not ice cream. Get with the times people, these are critical distinctions!!

Lessons Learned

Happy Holidays! This time of reflection (aka a vacation!) and I've had a chance to absorb the lessons and observations of a project team migrating from a traditional, multi-model environment over to a more centralized, 'single' database model environment over a full design phase. Now, take into account that this is for a 500K SF healthcare project, and that brings additional insight:

• Teamwork - This is a massive cultural transformation for any team - learning that anything you do within a model and how it overlaps with a half dozen other team members, and the learned communication is difficult to train. Overlay this with the traditional bell curve of varied skillsets and technical acclimation, and it becomes something that your BIM leads will need to focus on as a top priority.
• Component Development - Outsourcing is a good thing. 400+ medical equipment families that want to be developed as early as possible, plus casework, furniture, annotation, etc. is a huge volume of work that if you can offload it from your team, you will save a fair amount of additional work. Managing this resource library is a topic for a future rant... ;)
• Network - Current file management in the existing BIM apps is pretty sucky (technical term, involving a vacuum-like sound). To their credit, they are not networking companies, and to expect them to handle this much data to 20-40+ users at this point is probably pushing reality (sorry guys!).  
• Generation Gap - He who holds the pen controls the outcomes. Unfortunately, your users that are not in the model become increasingly separated from the content and output of the model/drawings/design/decision-making. Learning how to incorporate and educate these users on the processes and what the expectations of all team-members are will make your life much, much easier. Also, making sure they understand that Autocad methodologies are not the ultimate answer to architectural design and production is essential.
• Technical Balance - BIM requires that your team knows how to put a building together, not just 'draft'. Having the right balance of technical expertise, both in and out of the model, will produce a better entry point and model status before entering CD's.
• Sub-Contractors - A solid selection of design assist partners and engagement of them early in the process, and not just in an advisory but in a model-development role, will only help. They are worth their weight in pulling down costs and improving documentation/construction.
• Engineers - a) Get them on the same software platform, if possible. You will piss through file translation costs like nobody's business otherwise. b) Make sure they are producing models, and early. We don't work in a 2D world, everything has an X, Y, and Z dimension, and without their models you are leaving serious coordination and decision-making in shops or, worse, to be found in the field. $$$, enough said.
• Put your PA's to work - BIM enables your Project Architects to get to work early, establishing drawing standards, systematic design, and other projectwide standards as soon as you start the model. Nothing is wasted, and these standards can evolve as the project moves forward, but a good foundation is worth its weight by the time you hit construction documents.
• Communicate, communicate, communicate. Refer to my last post :)

As we move into the next phase, we will be looking at tighter construction integration, fast and heavy documentation, and probably a new batch of challenges. Stay tuned!

Zen and the Art of Sheet Setup

So, with this impending deadline, I've spent the last 48 hours setting up 70 some sheets as part of our drawing set. Ah, I can hear the virtual envy in your voices. But this has brought about some introspective thinking about how I would approach this time consuming and dramatically in-need-of-automating task:

• Rinse and Repeat - in a central database environment, it should be expected (unless noted otherwise) that a view will end up on a sheet. That being said, even though there have been great strides in making this more efficient, there is still a level of tediousness when setting up 200+ sheets, especially with plan blow-ups, etc.
  
• Think Indesign - Page layout apps have come a long way in the last 10 years, and CAD apps need to make the same strides. 'Heavy' processing of views is just tedious for large projects, wading from view lists to sheets, and easy guide snapping would be a good thing. Seriously.
• Lite is not just for Beer - With the heavy processing work occuring in the central model, a streamlined viewer or 'page layout' GUI would make life just dandy for large projects. Intelligent video card management, thumbnail placements, and only parsing the database for necessary information would make the process much more efficient and cut down the number of objects being thrown in anger around the office (we are now using only paper cups, and all bottle cap lids are confiscated in the kitchen).
  
• Group Therapy - Going back to multi-disciplanary central database models, we are currently carrying some of our consultants sheets in our BIM model, but they have no way to access and control the layout or content. Turning this into a central file for the entire family will not only make it easier to have one source of content, but allow for easier standardization of consultant sheets back to the main format and content management.
  

This is not meant to be a bitch-fest, but identification of a task that is hammering us from the efficiency side. A little more love in this area could both speed up and simplify this task as well as make it easier to push out to the entire extended team.

Food for thought, I'm going to bed.

G'night Jonboy,