WHAT ARE OUR REQUIREMENTS FOR BUILDING MODELS?
The requirements for a building model to be analyzed are always the same, regardless of whether you are working in the context of native modeling, i.e., "closed BIM", or receive the model via transport format, i.e., IFC.
With IFC, one more step has to be taken to get to this model: The correct setting of export options in the architecture software. Let's start with the general requirements for a model:
- The model must have defined spaces. Spaces are the starting point of any analysis. Consequently, it is imperative for an overall consideration that all building areas are "filled" with spaces. In early stages of planning, it is quite sufficient to define large areas or zones as "spaces". A smaller-scale consideration is only necessary when real room loads are required.
- the model, larger shafts must be identified as such. Not every slot or recessed gap in a wall for the drainage pipe needs to be marked, but the elevator shaft or the large shaft for the air ducts do. One reason for this is the easier detection from the "exterior": If there is no other room and no shaft behind a room surface, then it’s the "exterior". This can lead to incorrect readings in the absence of marked shafts. Another reason, of course, is the thermal consideration of these unconditioned areas. Marking the shafts is a task that is usually not done by the architect. Therefore, we offer tools on each platform that allow you, as a professional planner, to perform the definitions. These definitions are designed to remain valid even after the building model has been updated. Assuming the shaft still exists at about this location.
- A correct classification of the components is important for the comprehensibility and processability of the analysis results. It is not necessary that a wall or a window is "real", i.e., native architectural entities in the target system, it must only be defined on that spot so the machine can read in what the components represent. This is because a glass surface is initially difficult to distinguish from a concrete surface for the building analysis. It simply detects that the "wall structure" at the location of the window is different to the rest of the wall.
- the graphical detail for the analysis should be chosen reasonably. Modeled roof tiles, chamfers on concrete edges or fall protection on exterior windows are examples of nice details in the building model, but they are not very useful for building analysis. Interior finishes, such as baseboards, switches, and sockets, may also not be included in the analysis. Room boundaries should not depict every wall niche and tile joint but should have only as many individual surfaces as are necessary. Modeled door and window handles and frame details, on the other hand, do not interfere with the analysis because they are not used for it.
In addition to these general requirements, there are a few other things to consider when using IFC. Whether you use IFC 2x3 or IFC 4 for the export is of minor importance. The format specifications required for our use case are already all covered with IFC 2x3. The following aspects are more important:
- The correct "MVD" (Model View Definition) should be used. The MVD defines what is to be included in the IFC and how it is described. In case of IFC 2x3 it is the "Coordination View" and in case of IFC 4 the "Reference View".
- Openings (windows/doors) must be referenced via "openings" in walls
- The room boundaries must be included. It is important to export the "first level boundaries" - i.e., the simple spatial boundaries (six faces in the simple rectangular space).
- IFC4 can also transport "second level boundaries" - i.e., spatial boundaries already divided between neighboring spaces. This is usually implemented very poorly by the authoring environments, so our algorithm calculates this information independently in every case.
- correct convertibility of the component types to the associated IFC classes must be ensured. For example, have room boundaries been exported as IfcRelSpaceBoundary, walls as IfcWall, and "holes" for windows and doors as IfcOpeningElement?
- following graphical description types (Representation Type) for components and rooms are supported: SolidModels (SweptSolid, Brep, CSG, Clipping) and SurfaceModel (Tesselation). These are the common types that can be used to map all the essentials.
- Aligned project coordinates. Less important for the initial analysis, but even more important for coordination tasks in the further course of the project. Set them to a coordinate system. This means a "zero point" and an alignment of the building model.
With common professional architecture programs, all this is usually feasible at the "click of a button", though perhaps not on the first try. A coordination phase in which the various export options are tried and compared should always be scheduled.
CAN BUILDING MODELS DELIVER EVEN MORE (USEFUL) DATA?
The building geometry and its topology (adjacent rooms, shafts) are the most important data to extract from an architectural building model. In addition, a model can carry further information - also increasing in the planning progress - which can be directly incorporated into the load analyses. Among others:
- material information. The exact construction of walls, ceilings and roofs can be supplied directly in the model. Ideally, the structure is already modeled. This means that the individual component layers are available with their specific layer thicknesses. In this way, even difficult situations such as partial clinkering can be cleanly identified.
- Terrain data. From the simple input of a ground elevation to fully modeled terrain topologies, the information is used to determine the parts of the building that border the ground on the outside.
- Target states, i.e., data such as the target temperatures for heating and cooling agreed with the building owner, but also the required air conditioning can be anchored to the zones or rooms of the model.
- Loads, such as from persons, light or machines, can be stored via specific data or - depending on the platform - room profiles.
If this information is not stored in the model, it is captured in LINEAR Building by simple means. The data detected in this way continues to exist even after updates to the building model and does not have to be detected again and again.
However, they can be supplemented or overwritten at any time by data from the model as soon as the latter provides reliable information.
USE CASES TODAY AND TOMORROW
At the time of this article's publication, the new algorithm has not yet been released for productive use. We still must bring it to product maturity with models from everyday planning. Those of you who would like to contribute - especially with models from real projects - are cordially invited to contact us at preview@~@linear.de.
The first use case will be the IFC link for AutoCAD users. In the next step, we will also switch the well-known analysis of AutoCAD architecture models to the new algorithm. These models still remain the first choice for projects that need to do without (good) 3D models from the architect and where the specialist planner quickly creates a simple analysis model using the tools of the building manager.
In the final step, we plan to merge the new ideas and possibilities with the specifics of Revit-based building analysis to meet the highest quality standards on all platforms.
In addition to the obvious advantages of the new algorithm itself, cross-platform use allows us to implement and provide enhancements and customer requests for all users in one step.
Javier Castell Codesal