CAD Geometry vs Performance Analysis

With an increasing regulatory emphasis on energy efficiency and building performance analysis within the design process, the need for a smooth and hassle-free conversion from CAD tool to analysis engine is becoming critical. This article considers the issues associated with such a transition, looking in detail at the kind of information required by different performance analysis / simulation tools and what is actually available in a typical CAD drawing. It looks at the various options available, including the growing influence of Industry Foundation Classes (IFCs) and gbXML, and what their impacts might be.

Introduction

Unfortunately the tradtional way architects and designers create CAD drawings means that they are not all that useful when it comes to the computational analysis of building performance. Apart from indicating basic geometric layouts, they simply do not contain the range of material, operational and spatial information required by most simulation and analysis tools. Whilst some of the information in a 3D CAD model may be suitable for lighting and shadow analysis (where colour and transparency are the critical properties), it is almost entirely unsuitable in it's raw form for detailed thermal and acoustic studies.

2D CAD Drawings

Most traditional CAD design drawings tend to be 2D, existing only as a series of plans, sections and elevations. They include large numbers of lines there with the sole purpose of being interpreted by a human viewer. There are no hard and fast rules as to which layer particular lines should be on, what colour they should be assigned or what line-type to use - so the CAD program really has no clue what they are and why they are there. Only their context and a significant amount of human interpretation can tell whether a particular line represents a sheet of glass, part of a window frame, a wall layer boundary or the top of a skirting board.

3D CAD Drawings

Things get a little better with 3D CAD models in that it is easier to determine between a disconnected line (as in a layer boundary) and the top of a small prism. However, similarly, there are no hard and fast rules or conventions to automatically differentiate a skirting board from a very low wall, or a sheet of glass from the frame it sits in. So again this requires context and a significant amount of human interpretation.

Another important issue is that most CAD tools tend to be engineering-based and therefore do not know or care whether you are drawing a building or a gearbox. They deal with generic geometry not building elements, making it is extremely difficult to automatically determine whether any particular solid object represents a floor, wall or window frame. Some CAD tools such as ArchiCAD and Revit are starting to make these distinctions, but to exist in a diverse market they still need to be flexible enough to accommodate objects other than buildings.

The Real Problems

The results of all these issues mean that:

• There is usually no easy way of imbuing objects in a traditional CAD model with real architectural knowledge. The CAD tool simply cannot differentiate the prisms or polygons you generated to form the floor of a space from those you used for the walls and ceiling - unless you specifically adhere to a set of layer/linetype rules of your own devising.
• Most traditional CAD models have no real concept of spaces and zones, they exist solely as a by-product of the layout of disassociated geometric entities in the model. However, thermal and acoustic analysis requires such information in order to determine the average temperature in a room or the reverberation time of a space.
• Whilst it is possible to assign tokens, indicators or external references to individual objects in the drawing, it is not usually possible to apply detailed thermal, lighting or acoustic material properties. Data structures for this kind information simply do not exist in these models. Thus, you have to use links/references to external databases or establish your own set of rules based on specific material or layer names.
• Even if you could work out a way of embedding this kind of data, most commonly used geometry interchange formats completely ignore embedded metadata, so all your hard work will usually be lost during export because of the limitations imposed on import formats by the analysis tool.

In many cases, it is often quicker to generate the model within the analysis tool itself rather than endure the hassles of indirect translation and all the checking and verification involved. This is the approach taken by many engineering firms who often have a whole section of their staff dedicated to this task alone.

This issue was a major impetus in the development of ECOTECT, which provides a useful interface for generating model geometry, assigning all the zonal, material and operational parameters, and then exporting these to the native input files for a wide range of different analysis engines.

However, experience has shown time and again that the difficulties of moving data between different tools mean that most designers just do not do it - preferring to work solely within the particular CAD tool they are used to. As a result, engineers and consultants spend a large part of what could have been analysis time simply redrawing projects to suit whatever simulation tools that they are used to. Hence the groans and wasted fees that typically accompany each major design iteration.

In a perfect world where the process was much simpler and easier, and all the right information could be transferred back and forth, the role of performance analysis and simulation in the design process would be completely transformed. Deep down, all designers are curious to know the potential performance impacts of their decisions - after all, even the smallest design changes can affect many different performance criteria so it is much better to know than not know. The smoother flow of information means that designers could avail themselves of a faster and cheaper feedback service from their engineers and consultants. Moreover, it would also mean that designers themselves could undertake many of the initial aspects of the building analysis, iterating through a wide range of options before calling in their engineers for verification and validation.

So the question really is just how far away are we from this perfect world ?

Building Information Models

Things have been changing, especially with the rise of the Building Information Model (BIM). Originally attributed to the ideas of Dr. Charles Eastman, this refers to systems that store not only the 3D geometry of a building, but all its functional requirements, material properties, operational behaviours, construction scheduling and lifecycle maintenance. These are essentially 4D building databases which can store geometric amd many other types of information that can also be related to a time structure.

From these ideas developed a project to store this information in an industry standard way so that it was available and accessible to all members of the design team and to different sections of the building industry. The result was Industry Foundation Classes (IFCs), a schema for describing all the different aspects of a building design as well as their complex inter-relationships.

Their use offers enormous potential benefits at all stages of a building project - allowing designers, engineers, analysts, quantity surveyors and the builder to dip into a central pool of shared information and automatically extract the data they need to perform their jobs.

Ongoing development of IFCs have also introduced some very important concepts crucial to the interoperability of CAD and analysis tools. Chief among these has been the concept of spaces and zones, fundamentally challenging the way CAD tools organise building information and how designers must generate their building models.

Such zonal and spatial information is vital in the design of building services, thankfully seen by the IFC developers as equal in importance to the form and fabric of the building. A computational understanding of the spatial relationship between room volumes is also central to accurate thermal and acoustic analysis.

Not the Ultimate Solution

Whilst IFCs have been around for some time, their full implementation within CAD tools has only been quite recent. Whilst there is no doubt that IFCs or some derivative from them represents the future of CAD interoperability, there are some very real reasons why they do not represent an immediate solution to the CAD / analysis transfer problem.

The main problem is that the IFC classes must be all things to all people. They need to store enough information to be useful to all aspects of the industry - designers, analysists, structural engineers, services engineers, quantity surveyors, building contractors and, eventually, facilities managers - which means being flexible.

With flexibility comes some level of ambiguity. For example, IFC files support several different ways of describing geometry. This includes a high level definition of the main characteristics of each building element in which, for example, a wall is defined by its centre line and a sectional profile. It may even include a series of constructive solid geometry (CSG) operations that have been applied to the wall. At the same time, the wall can also be defined as a series of planar polyloops representing each of its faces, or as a set of X3D proxy geometry. Any or all of these variants may be present in the IFC file.

To see why this might represent an ambiguity problem, consider the use of the IFC file by the quantity surveyor looking to extract simple area and length data to allow easy quantity take-offs - also considering that the cost of fitted work surfaces are typically calculated based on the linear length of each bench. When the designer draws a bench in the model, they will typically construct it as a series of rectangular prisms to represent each part of its structure so that it 'looks' like a bench. Fair enough, but how does the IFC generator determine exactly which surface in all these prisms to take the all important measurement from? Also, what happens for very thin benches where the depth is larger than the width - how does the take-off tool 'decide' which dimension to use? Do all CAD implementations export bench data in exactly the same way?

One further problem is the sheer complexity of the IFC format. Whilst the user is unlikely to notice this, it greatly impacts on the developers of analysis tools that wish to support it. The STEP platform requires a large library of functions to load and interpret it. Whilst there are some open-source implementations, the majority are proprietary and require licence fees. Also support for the flexibile geometric definitions may not be a problem for a CAD tool, but a simple analysis program is unlikely to support complex constructive solid geometry and the boolean operations that may be required. This means that the analysis tool must rely on the exporting program having an option to include the simplified polygonal representations - and that the user has actually selected it.

gbXML

Green Building Extensible Markup Language (gbXML) is an another schema developed by GeoPraxis for use in their Green Building Studio product - an online energy analysis advising tool. As such, it is very much geared towards converting a CAD model into input for the DOE-2 energy analysis tool and, more recently, EnergyPlus.

Having such a relatively narrow focus, its definitions and data requirements can be very specific. In fact, it's geometric requirements deal only with spatial volumes and thermal zones with relatively simple polygonal boundary surfaces. This means that any CAD tool that supports gbXML must export its complex model information in this simplified form.

This is a great benefit for the analysis tool developer as the result is a relatively easy file format to read in which the spaces, zones, surfaces and materials are all unambiguously defined.

With all the recent legislative emphasis on energy efficiency in buildings, thermal analysis is becoming an increasingly important design consideration. As it offers an immediate solution to a pressing problem, gbXML is fast becoming a defacto industry standard for defining thermal models, with support already from CAD tools such as ArchiCAD, Revit and AutoCAD Architectural Desktop.

This format too is not perfect. It is very much intended for a non-visual representation of a building. The surfaces between zones and those exposed to the outside (or underground) are defined separately from the internal space boundaries. The geometry is always defined with North in the positive Y-axis, yet there is no record of the original orientation. This makes it impossible to re-orient imported models such that their surfaces align with the major cartesian axis if the original orientation was anything other than due north.

The Solution

Basically, the upshot is that there is no single absolute solution for the straight conversion of CAD geometry to a format suitable for all forms of performance analysis or simulation. This means that you will need to make a judgement on the best method to use for different situations, based on both the type of analysis you intend performing and the export capabilities of the CAD tool you use.

Thermal and Acoustic Analysis

Both thermal and acoustic analysis require the definition of zones within your model to create a series of distinct homogeneous volumes of air. Without these the concept of an average room air temperature or a statistical reverberation time simply does not make sense - so your analysis will be meaningless.

Additionally, both types of analysis do not require detailed geometric models. In fact, they are almost always more accurate when based on simplified models without the skirting boards, window frames and light fittings typically added for visual effect. This is because the overall acoustic and thermal properties of the different building elements are already aggregated: the U-value and transmittance of a window already includes frame effects; statistical acoustics formulae already assume scattering by small surfaces within each room; etc.

Thus, the best way to export this information is by defining zones within your CAD model and exporting a gbXML file. ECOTECT now supports the import of gbXML files directly and will automatically accommodate material thicknesses and surface offsets to create a consistent visual model of your building.

If your CAD tool does not support zones and/or gbXML, then you will have to use a less specific format and manipulate your layers, pen types and material definitions such that you can extract the information you need once you get the data into your analysis tool. This may mean generating summary or simplified geometry on special layers within your CAD model by tracing over parts of the building. It may also mean using naming conventions that you will recognise in the zones or materials displayed in the analysis tool.

The best format to import full 3D model files into ECOTECT is the 3DS file. This is one of the most popular formats for exchanging models on the web (see http://www.3dcafe.com/), so most CAD and modelling tools now support it (except Microstation and a few of others).

For 2D plan or section drawings, the DXF file is still usually the best, however for drawings where you want complex curves, hatchings or dimensions to come in, you can simply plot the drawing to a HPGL file (Hewlett Packard Graphics Language) and then import and rescale it in ECOTECT.

If the particular modeller you are using does not support these formats, you can always download tools from the web such as Rhino that will import whatever you can provide, and then export either supported format.

ECOTECT now supports a wide range of standard import file formats. However, as with most analysis tools, the author does not pretend to be an expert in all geometric file formats so has likely missed or misinterpreted some of the subtleties in several of these standards. Whilst the facilities in ECOTECT should allow you to import the majority of what you need, you may have to fiddle around a little in order to overcome some of the quirks and idiosyncracies you could encounter.

Importing 3DS Files

3DS files are usually the best solution when importing/exporting full 3D models from CAD tools such as ArchiCAD, AutoCAD or SketchUp for shadow and/or lighting analysis. These files maintain material names and colours assigned to each object, as well as any cameras and lights set up in the model. Complex solid objects are converted to simple triangulated meshes and basic object groupings and layers are retained. This means that it is possible to make use of the automatic zone and material attribution functions offered in the new File > Import... > 3D CAD Geometry dialog.

There is also a new option to automatically merge coincident triangles. When selected, ECOTECT will search the imported geometry for all coplanar triangles that share two vertices and attempt to amalgamate them together into a single complex polygon. This has the advantage of reducing the number of objects in the model, but with very complex and concave polygons, may increase redraw times in the OpenGL Visualisation Page.

You will usually have to experiment with the scale when importing 3DS files as they are rarely drawn with their base dimensions in millimetres - the basic units used in ECOTECT. In a 3D CAD model, users are free to use whatever units they wish. Thus, if you go through an import process and nothing appears, this usually means that the imported geometry is either way too large or far too small to be seen. In these cases you will need to either immediately undo the import and try a different scale or, with the imported objects selected, use the Scale function in the Object Transformation Tab.

Importing DXF Files

For 2D plan or section drawings, the DXF file is still usually the best. This includes lines, polylines, 3D faces, polyface meshes and other simple 3D elements. It also includes ACIS solids information, however this is embedded in a proprietary format for which you need to licence an interpreter, and the ACIS solid modelling system to then interpret utilise them. ECOTECT therefore ignores ACIS solids and will warn you that it has done so when the import is complete.

In some instances you may find that some blocks do not import with the rest of the geometry. If this happens, you should first use the explode command in AutoCAD to break the block into its constituent components. You may need to do this more than once to ensure that each object is extracted from embedded blocks.

Generating and Importing Plot Files

Importing a plot (PLT) file can be a very flexible last resort when dealing with different CAD files, complex cross-referenced projects or when you want to include complex splines, hatchings or dimensional text. This basically involves setting up a HPGL printer in your CAD program or even as a standard Windows printer. I have generally found that the best plotter to emulate is a HP7580b as it's drivers come standard with MS Windows and it uses standard HPGL rather than HPGL2.

Once you have the printer set up, make sure you print to a file - there is usually a checkbox in the standard Windows Print Dialog, however most CAD programs also allow you to set up the printer to do this automatically for spooling programs.

To import the file, use the Import > General Data Files... item in the File menu. You should probably leave the scale as 1:1 (as you will not know the exact translation from printed page to real world) and then use the Scale function in the Object Transformation Tab.