Polantis presents the Case Study of the Rector BIM approach: go behind the scenes during the creation of systems for one of the major players in the concrete materials manufacturing market.
The BIM approach
In September 2015, Polantis put the Rector CAD and BIM products online: the “ThermoPreslab and Masonry Wall” and the “ThermoPreslab and ThermoPrewall”.
What makes the manufacturer’s products unique? A part of the system is designed in the factory (with integrated iron framework) and the concrete part is poured at the construction site.
The outcome? Easier assembly and incomparable construction quality, specifically with very strong thermal performance (no thermal bridges).
For Polantis, modeling Rector’s systems was a challenge: how do you design a multilayer object and ensure that it is perfectly adapted to the project?
Test 1: “the super product”
With Rector’s full collaboration, the team of architects in charge of the project launched a study in order to determine the best way of understanding product modeling.
First, it was understood that the walls and flooring would be treated in the same way because the construction system was the same.
Next, the teams decided to create a super product. The iron framework would be distributed automatically in the part treated: this was the insurance that the product would be represented from “the inside” with all of the elements that constitute it.
However, very quickly, the team discovered several obstacles to modeling this product.
The iron framework, which became parameter-adjustable, could not be properly integrated with complex-shaped parts and was not adaptable to all types of surfaces.
What’s more, the Rector iron framework integrates into two principal layers of the system, which could not be parameter-adjustable in Revit.
Lastly, the question was raised regarding the premier user of the products: an architect did not have any utility to exploit this super product which, in addition to being slow to load in the model, included information that was more useful in design offices.
The study, therefore, revealed that this product was too elaborate.
A multilayer system
In parallel to the meeting with Rector, Polantis began to collaborate with Siplast (a specialist in impermeability). As the two products are successive layers of insulation, the reflection for modeling the Siplast products was also useful for reflections on Rector products.
Similarly, the agreement was to design a .rvt format system in which these layers would be represented: the insulation layer, the concrete layer, etc. The iron framework would no longer be represented on 3D elements, but on 2D elements and on other visuals provided with the product when it is downloaded.
The difference between the .rvt format and the .rfa format
On a Revit project, the model is made in .rvt: it brings together all the elements of the project; in some respects, it is the anatomy of the building. The .rvt format model includes the nomenclature, materials, parameters, geolocation…all possible information. With all this information included, it is possible to communicate with the other trades involved in the design & build chain.
An object in the .rfa format belongs in fact to a Revit family. These are objects that can be taken and then simply moved, like a window, a chair, or a lighting fixture. We talk about them in terms of family because there is an organization between such objects: some are parents while others are the children or grandchildren.
The major interest in having designed the Rector system in the .rvt format resides in the fact that it can, unlike the .rfa format, contain information in the form of text or image files.
The “I” in BIM stands for Information
For example, modeling an .rvt object lets you integrate the iron framework layer into the system, not in terms of its geometry but in terms of its information.
This proved to be particularly necessary because, for example, if it was integrated into the product in the form of a layer, without, however, its parameters set by the Polantis teams, it would be up to the architect to decide how to place the iron framework, thereby involving the architect’s liability in the event of a calculation error.
The importance of the information provided is at a maximum in the case of the Rector BIM objects: in order not to overload the digital model, the product is visually “lightened” and represented more simply, but all of its qualities, its placement mode, unique points and performance information, and standards are associated with the object at the time of downloading.
A “hub” object
In order to best exploit this informational dimension, the agreement with Rector was to conceive of the modeled systems as “hubs”:
- “fixed” data was added into the object parameters.
- Computer images were created to help understand the “inside” of the system and understand how it is placed in the construction site.
- Data that may evolve were added in the form of a URL link that leads to the Rector site, and product information is continually updated: regulation, standards, label, performance, economic comparative information, etc.
- The composition table provided with the object included all of the unique points that allow for best product placement: the unique points designed by the Polantis teams (and validated with Rector) are intended to be copied and pasted by the object user.
Information on acoustic, seismic, and fire-resistance performance
The BIM for all the actors involved in construction
Ultimately, this “hub object” proposed by Rector works to serve all the users of the Design & Build chain perfectly. Here is a list of the actors who are concerned with BIM objects:
- Thermal BEs
- Construction Companies
- Inspection Offices
To be useful for an ever growing number of actors, the Rector BIM objects are also available for the ArchiCAD software program. The objects modeled for Allplan are currently in production by the Polantis teams.