Phase II - Masonry Wall Model Definition

This project is at the core of masonry BIM. Because masonry BIM is a computational model of masonry construction, and masonry walls are the fundamental assembly in masonry construction, it is critical that the data representation of the masonry wall support all of the functionality that is envisioned for BIM-M. Currently, it is simply not computationally practical for BIM software to track individual masonry units in an entire building. Therefore the masonry BIM data structure must include the definition of wall types, and must provide the means to map these wall types onto regular and irregular regions on wall surfaces.

This project will develop requirements for the digital representation of masonry walls in BIM systems. This will lead to the development of masonry families, through which a set of masonry units (extracted from the data structure defined in the masonry unit project) are arrayed according to established rules to take a generic wall in BIM and represent it as a fully-described masonry wall. It is anticipated that these walls will be represented in different levels of detail depending on the needs of the BIM user. For example, in early stages of design and on large- scale buildings, walls will be represented as regions without populated masonry units (wireframe mode). As more detail is required, these regions will be populated as masonry units represented as 2-D polygons, and finally as full 3-D photorealistic rending with masonry units modeled as solids. In addition, the wall definition must include the propagation of masonry units in various bonding pattern with modular coordination of masonry veneer and backup systems.

Project Tasks

  1. Define high-level classes that must be required to be defined in masonry BIM: veneers, bonding patterns, masonry backup systems, openings, pilaster, etc. and methods for generating objects based on these classes. Adapt to and coordinate with the masonry hierarchy established in the BIM for masonry benchmark project.
  2. Formalize the concept of a masonry family, which is a complete set of objects needed to define the veneer masonry and its backup system within a given bounded region in the BIM system.
  3. Identify rules that define the relationships between objects. These will be the parametric rules that control bonding patterns and the relationship between veneer and backup bonding. These rules will determine how bonding patterns react to the placement of door and window openings, to the placement of floors and roof systems, and how the bonding systems will react to the region boundaries in which a given masonry family is mapped.
  4. Define strategies for regions to adapt to modularity of the masonry systems embedded in them.
  5. Define a set of views of the masonry system, from lightweight views that should be computationally tolerable to detailed view suitable for photorealistic rending and virtual construction.
  6. Develop an interface that allows for the importing of masonry units (from the masonry unit project) into a wall definition.
  7. Develop interface requirements for the input of wall types (denoted a “wall definition module”) to be implemented in BIM.
  8. Work with software vendors to prototype/validate initial data structure for masonry wall definitions.
  9. Publish a draft specification for wall data model.

Participants

The project will be led by Georgia Tech and staffed for 18 months by a DBL graduate student and a post-doctoral assistant.

Masonry Industry Project Manager and TMS BIM-M Chair

Jamie Davis, P.E.

Working Groups Chairs

Maria Viteri - architectural
Tomas Amor, P.E. - structural

Prime Contractor

Digital Building Laboratory, Georgia Institute of Technology (GT)
Russell Gentry - Project Manager

Milestones Anticipated

July 2014 - Submit article for SMART dynamics of masonry magazine on Level of Development (LOD) progress.
October 2014 - LOD proposal before BIM Forum, Dallas
October 10, 2014 - TMS BIM-M Committee meets in Scottsdale, AZ
October 11, 2014 - presentation at TMS Annual Meeting


* Some of the descriptions in this project are based on the definitions used in object-oriented programming, and the terms “class” and “object” have specific meanings in this context.