The Quantum Object Model
Quantum as an information model is based on objects and relations (an object graph), where objects have attributes. An object type in Quantum represents some modular concept in the ontology: a building, a floor of a building, a component of some equipment, or a medium representing a type of liquid. A relation type describes some kind of relationship between two objects. An object may be related to other objects in very specific ways, depending on the object types being related. Relating this back to object oriented programming, an object type is analogous to a class, and an object1 analogous to an instance of a class. Objects and relations are analogous to nodes and directed edges in a graph theory framework. Quantum is more akin to a labeled property graph than a semantic graph2.
We organize the different types of objects into domains. The domains are intended to group object types in a meaningful way. This was motivated by our experience attempting to use different data standards, whose definitions and documentation were primarily flat and required digging to understand how things related to one another. A brief summary of the different domains is provided in the table below.
Properties are used frequently in Quantum as a generic mechanism to associate quantitative attributes to objects. Properties can have units (or be dimensionless), and can have a literal value or be computed by a series of operators, literals, or other properties. For example, we may wish to express the area, height, and volume (three different properties) of a zone. In a simplistic calculation, we might say that the zone volume property is computed via the expression: volume=area*height, where both area and height are properties with literal numeric values. Quantum’s property and equation object types enable users to express simple and complex mathematical relationships. In addition to a current value, properties can have both historical data (a history) or predicted data (a prediction).
A deeper dive on properties, behaviors, equations and time-series data is forthcoming, however, the primary concept to understand right now is that a property can be associated with many different object types in Quantum.
Site, Environment, and Building
The site, environment, and building domains are highly related to one another. A site has one or more buildings and is associated with a location object type in the environment domain. A building has one or more floors (or stories), each floor has one or more zones (or spaces), a zone has some number of surfaces, surfaces are composed of constructions and layers, which then have an associated media. The design goal for the different object types in the building domain is to capture information pertaining to three primary aspects of a building: the architectural representation (form), the functional representation (purpose), and the thermal representation (energy balance). Other information models may consider one or two of these aspects, leading to the creation and maintenance of multiple building representations throughout the building design process. Our goal in Quantum is to strike the correct balance.
The architectural form of the building provides detailed 3D geometry and information about materials; the functional representation enables understanding of the design intent for different areas of the building; the thermal representation derives from the architectural form and the function of building areas to enable understanding of how energy moves throughout the building. A deeper dive on understanding the thermal and functional representation of a building (constructions, layers, and media) is forthcoming; the following section on geometry provides an introduction to how 3D geometry is represented in Quantum.
The site has a location, which captures the address, elevation, and other geographic information. Since the environment that a building operates in is critical for optimizing equipment operations and achieving its goals, a location should always be associated with at least one weathersource, although multiple weathersources can be used. For example, at the beginning of a project we may know the location of a building, and associate a static TMY33 file as a weathersource for that building. Further in the process, someone may wish to add a near real-time weather api as a weathersource for a building—both of these are possible with Quantum.
The basic element of our building geometry representation is the zone (architectural space), which represents a portion of the building dedicated to a purpose. A key design goal for representing spaces in Quantum was to focus on defining spaces that exist entirely in their own right, without knowing it’s location or context in the building. Rather than spaces being derived from walls, surfaces, or vertices, the shape of the space is defined first, and in coordination with other spaces in the building, the walls, surfaces, and adjacencies are actually derived from the intersection of spaces. Spaces are usually defined by the areas encapsulated by the constructed (physical) walls of the building, such as a typical office. However, building spaces don’t always break up according to physical boundaries and often require logical boundaries. We conceptualize logical boundaries as an “air boundary.”
Vertices and Shapes
The basic geometric concept is a shape. A shape is an ordered list of vertices that are connected together. The ordering is very important, as it defines the path of traversal for the shape, enabling both convex and concave shapes. The vertices usually lie in a flat 2D plane. They can either be a loop (closed) or have start and end points (open). The shape concept is also called a path, poly line, or contour in other software (analogous concepts can be found in IFC, EnergyPlus, AutoCAD, SVG, and others). Note that shapes are similar to polygons, but are not necessarily composed entirely of straight line connections. There may be a curve connecting two vertices instead of a straight line.
The key advantage of this structure is that it conveys adjacency information and in the closed case has an inside/outside. We know which segments are connected together. We can query whether points are in the shape. Shapes are used in a variety of ways throughout Quantum; a few examples include: 1) defining floor plans, 2) defining custom shaped apertures, 3) defining sub-surface geometry.
Floor Plan Shapes
The primary use of shapes for us is to describe the floor plan of a space. In this case each vertex represents the beginning of a wall around the loop. The length of the wall is determined by the distance to the next vertex. The loop encloses the boundary of the space, and is often referred to as the boundary shape. The boundary shape determines the floor plan of any particular zone. The floor plan is then extruded by a height to get the shape of the room. The exact shape of each wall, as well as the floor and ceiling is implicit in this model. You must refer to the context of the wall in the shape to understand its length and height.
A surface is a logical piece of construction in a space such as a wall, door, or window. Whereas shapes are very concrete in the sense that they exist as they are being defined, surfaces are more conceptual because they are really a consequence of the geometry definition, meaning, they only exist after the geometry is defined. Even within the realm of surfaces, there are certain surface types that are more conceptual than others. For example, the only purpose of a boundary surface is to capture the shape of the space, whereas other surface types are intended to convey thermal characteristics of the surface (layers, and others). The surface type is the mechanism used to convey the purpose of a surface. There currently exist 11 different surface types:
Surfaces are related to one another via two primary mechanisms:
- A surface is related to the vertex contained by another surfaces’ shape. For example, this is how a wall surface is related to a boundary surface of a space. We refer to these as surfaces along the boundary path.
- Surfaces are related to one another via an adjacency. This is how fenestration (windows, doors) are related to a wall, or how subsurfaces are related to a parent surface (more details on this later).
Surfaces can be adjacent to other surfaces, but adjacencies are a more generic tool for relating things to surfaces. For example, they enable us to relate an equipment or component to a surface. More details on how the exact location of an arbitrary thing is specified in relation to a surface will come later.
Multiple Spaces and the Role of SubSurfaces
So far, we have mostly focused on how surfaces and shapes relate to a building composed of a single space, but this is not a very realistic picture of a building. When we begin looking at buildings having multiple zones, intersections between surfaces become very important.
A few crucial points to reiterate before diving into this topic:
- Spaces are defined entirely from the inside
- The majority of the geometry definition of a space can be traced back to a single boundary shape, with all of the surfaces occurring as a consequence of this boundary shape definition.
This is what enables us to move spaces around in 3D very freely. The wall surfaces of a space are really just a consequence of the boundary shape definition—they do not depend on how two spaces are situated in relation to one another. That said, certain information only becomes known when spaces are placed in 3D space relative to one another. This is the case for surface intersections, as demonstrated below.
This is the primary role that subsurface surface types play—they are surfaces that are derived based on intersections of other surfaces. This occurs with:
- Floors intersecting ceilings of spaces below them
- Walls intersecting walls of neighboring spaces
Some important characteristics of subsurfaces.
- Subsurfaces are algorithmically generated, not user defined.
- Subsurfaces represent a portion of a surface between two spaces, or between a space and some external boundary condition (outside, ground). They are adjacent to either one or two surfaces, which are referred to as their parent surfaces.
- Subsurfaces do not overlap other subsurfaces. Subsurfaces represent the smallest unit of division. They cannot be the parent adjacency to any other surface.
- Subsurfaces have their own shape.
- Sometimes also referred to as entities.