Effectivity of BIM transfer of structural models between programs for engineers

The paper describes the verification of the quality of the data transfer between selected software dedicated to generation of building models and for their analysis using the finite element method. For comparison, models of two typical structures are constructed: a steel truss hall and a multi-storey reinforced concrete building. Both models are created simultaneously in two programs: Autodesk Revit and Tekla Structures. Next, these models are exported to computational packages: Autodesk Robot, Dlubal RFEM and SCIA Engineer. Different options of data transfer are considered, in particular: a direct link between programs as well as via open formats. The scope and limitations of the data exchange are determined in each case. Juxtaposition of the effectiveness of different transfer methods for such typical building models are helpful at the stage of cooperation between the architect and the structural designer. In addition, pilot results of a finite element static analysis for the steel hall model are also compared.


Introduction
The origins of BIM technology date back to the 1970s and 1980s. The acronym BIM was initially defined only as Building Information Model. Even before the era of computerization in design offices and development of CAD (Computer Aided Design), the idea of parametric design with the use of geometry objects hierarchically ordered, i.e. according to the BDS (Building Description System), was considered [1]. This approach means storing information of the model description optimally, i.e., the geometry of the position and shape of complex elements are related to the topology and their efficient assembly using basic solids. Another aspect of introducing BIM technology originates from efficient management of the investment process, including also the construction process, where the key issues are the efficient transfer of information regarding the project and realisation of the investment (as well as how the facility operates) between industry teams within established rules and defined relationships [2]. The term BIM can be defined in different ways [3], the range of applications at the early stage of the design is very wide and may include many detailed activities, such as downloading of virtual maps as a base of terrain for building a model [4] or e.g. preparation of a schedule and cost estimate integrated with the model [5]. The most common explanation of the acronym BIM is Building Information Modeling, since the whole process of modeling is taken into account and different data connected with designed building objects are stored. Not only designers or investors may be the users of various information about the model, but also, during the facility operation, the companies providing daily media or even emergency services in the event of some disaster of the structure can use BIM based data. Therefore, the use of BIM technology may cover an entire "life cycle" of the object [6]. The essential issue of a properly designed model is fast access to relevant information. The acronym BIM can be then considered as an extension of the term Building Information Management, which refers to the rational management of information concerning a building object's model. Such proper management also ensures the appropriate choice of the method of transferring the model's data by designers of particular branches, which should cooperate with each other in the most together efficient way. A chronological overview of the first tools developed and used for CAD and BIM can be found in e.g. [7], [8]. Various aspects of their use, already in accordance of the idea of BIM and also in terms of data transfer, are extensively described, e.g. in [6], [8]- [10]. Moreover, the perspectives on the further development and future of BIM are included, for example, in [3] and [11]. The future of BIM may be related to management of comprehensive yet integrated database of information for a group of building objects, rather than just the limit of working collaboratively with an integrated model for an individual building, see e.g. in [8].
This paper focuses on the quality of transferred information for a building model, where the transfer is directed from architect to structural designers using tools intended for these industries, i.e. for AEC (Architecture, Engineering & Construction) designers. The effectiveness of popular engineering programs is analysed in the context of the model obtained after the data transfer concludes. In order to make an objective assessment, two typical building models -a steel hall and a reinforced concrete structure -are created in Autodesk Revit 2020 [12] (hereafter referred to as REVIT) and Tekla Structures 2019i [13] (hereafter referred to as TEKLA) and then exported to the following computational software: Autodesk Robot Structural Analysis Professional 2020 [14] (hereafter referred to as ROBOT), Dlubal RFEM 5 [15] (hereafter referred to as RFEM) and SCIA Engineer 20 [16] (hereafter referred to as SCIA). All these programs are supported by the Finite Element Method (FEM). The data transfer is carried out in different ways: by directly linking the programs, utilising plug-ins or using a selected open standardised format, e.g. IFC (Industry Foundation Classes).
There is, of course, a native format-based data exchange that involves uploading a file which is recognised as default by one of the employed programs. This type of data exchange is applied when both programs, source and target, cannot be installed on the same computer. The main disadvantage of this approach can be the iterative transfer, repeated after each saved change made to the model, which can lead to excessive time-consumption and mistakes when working on the current version of the model. Writing and reading files exclusively in native formats is not discussed in this paper.
Direct links work for so-called real-time data exchange but usually require both programs to be installed on the same computer and corresponding knowledge of one or a team of users who design together. This approach is applicable during intentional iterative modeling of a building object or when multiple adjustments of a constructed model are allowed. In this paper, the type of data transfer is realised using applications embedded in the software where the model is generated or by special plug-ins supported by source (REVIT or TEKLA) or even target (e.g. RFEM) programs.
Data transfer via open format does not require the presence of two programs, and is even independent of used software, since it is supported by some or most of the programs of different industries. On the other hand, the use of a standardised format can lead to many errors in the model because this type of transfer can be underdeveloped. Producers of the software firstly guarantee the correctness of the data exchange via their own recommended native format. The IFC file seems to be the most popular type of open, standardised format, and many papers are still published on using it as a medium for data exchange, see e.g. [17] and [18]. The problem of the quality of data transfer via the IFC format is shown in Sections 3.1-3.3 on the example of models of both structures. However, it is worth noting that alternative file formats also exist, e.g. CIS/2 (CIMsteel Integration Standards) for steel structures, cf. [19] and [20]. In this paper, the steel hall model is transferred by various manners, i.e. from TEKLA using CIS/2 or DSTV standards.
The most basic criterion for effective model transfer can be the completeness of the representation of its geometry in space. However, there are other requirements that should ensure correct BIM transfer. In this paper, the material characteristics and correctness of profiles are also verified. Transferred information should be complete, as accurate as possible (depending on LOD, i.e. Level of Development), unambiguous and understandable, and also include, among other things, attributes of a given element and its relations with respect to the whole model and neighbouring elements, if necessary, cf. [21]. The need of correction in the model after export can also be a measure of quality, which has been verified for models presented below. The evaluation of data exchange between engineering software developed for related and various industries is still a contemporary topic that requires attention, see e.g. [22]- [24]. Another aspect of comprehensive data transfer testing includes generating a model consisting of components with different geometries and mutual affiliations, such as in [25]. In this paper, models are verified for two typical structures, but composed of elements commonly used in construction.

Considered models of structures
The subject of comparison are two models of: a steel hall structure and a reinforced concrete building structure. The analysis of the efficiency of data transfer for such typical structures is the basic criterion for selecting verified models. Although their geometry is not complex, incorporation of the various components, the interrelationships between the elements and mutual connections that are characteristic of a given structure allow to carry out a thorough overview of the information flow in accordance with the concept of BIM, see also [25]. Steel hall and reinforced concrete building models are, as it is well known, characterised by a predominant material of construction and specific type of structural elements.
Steel structures consist primarily of member structures, and particular attention must be paid to precision when generating the model. The ends of the bars in a joint should coincide precisely at a common point. Even by a minimum distance, a misalignment can lead to the disconnection of structural elements in the model and, consequently, to the lack of the common node at this point. The steel structure, in this case, is a truss hall 28.8 m wide by 60 m long. The hall's total height from the foundation level to the top of the ridge is 7.3 m, the height of the columns on the sides measures 5.53 m and the usable height is 4.5 m. The truss girders on the columns are spaced every 6 m along the hall. The roof slope is approximately 7 degrees. The load-bearing girders and their longitudinal bracing are made of round pipes. Steel columns are modelled as HEB I-sections, purlins as IPE-sections and longitudinal bracings of columns as channels. The hall model was built in REVIT from an AutoCAD underlay to ensure an accurate mapping of geometry. It is worth to mention to how the structure's axes and levels are prepared, as well as the position of elements aligned with respect to the profiles' symmetry axes. Taking care of the correct position of the bars affects the quality of the analytical model. When the model in TEKLA is constructed, its legibility can be enhanced by applying colour coding to the structural members, which are grouped by classes. Figure 1 shows the view of physical models of the steel hall structure formed in both programs. The second model of the reinforced concrete structure is shown in Fig. 2. The building is composed of six above-ground storeys and one underground storey. Its total height read at the slab axes is 20.67 m, with the thickness of the foundation slab being 0.5 m and the thickness of the floor slab 0.2 m. The structure includes a system of columns, beams and floor slabs, stiffened by the communication riser walls and the underground storey. In addition, balcony cantilevers are modelled in one corner. On two storeys, the floor slab's shape is modified to take into account the direct connection of column and beam elements. The axial spacing of the columns is 4 or 5 m, depending on their position. The shape of the reinforced concrete structure is based on a stepped polygon plan, as shown in Fig. 3. When a model of a reinforced concrete structure in REVIT or TEKLA is generated, attention must be paid to the fact that there are additional surface elements and, consequently, there are various manual or automatic options provided by the software to so-called "pull" them to the nodes. Users should setup sufficient accuracy in tools' menu of the given program to activate snap commands during modeling of the structure. The alignment of structural elements, e.g. floors and beams, is an important issue. Both programs are characterised by different improvements, e.g. REVIT recognises the ends of elements depending on the connection type, while TEKLA allows the use of built-in components, e.g. stair treads.

Data transfer to ROBOT
The first transfer discussed is unique because it involves two programs from the same company -Autodesk. In REVIT, there is a built-in tool for integrating with ROBOT, which is operated using the dialogue box shown in Fig. 4. The data transfer can take place once the analytical model is formed. Direct Link between the programs ensures not only the possibility of exporting the model but also updating it after changes are made. Additionally, it is possible to save the model as a *.smxx file if both programs cannot be installed on the same computer. Direct Link also allows data transfer in both directions, i.e. it is possible to import the model into REVIT after FEM computations have been performed in ROBOT, so there is a return transfer option.
The resulting steel hall model is prepared for calculation because the quality level of transmitted information is very high. After the transfer in ROBOT, not only is the geometry of the hall model complete, but so are the corresponding cross-sections, materials, loads, supports, connections, and axes. This model remains loss-free and does not need to be corrected. An almost identical effect is obtained for the model of the reinforced concrete building structure. It is worth mentioning that the two-dimensional elements are divided, as planned, into walls and floor slabs with the correct panel thickness. The only issue is with the stair flights and landings, but this is due to the fact that they cannot be generated in the analytical model version. The view of both the structure models after having been exported from ROBOT is shown in Fig. 5. After making changes in ROBOT, the return transfer of the hall model gives the correct representation in REVIT, and therefore it can be subjected to further information exchanges. In this case, Direct Link significantly reduces the number of errors in subsequent updates of the model. Unfortunately, making changes to the reinforced concrete building model in ROBOT subsequently causes errors when imported back into REVIT and transferred to the physical model. There is a partial overlap of some surface components. From the users perspective, the concrete type material mistakenly takes the form of a ceramic pattern. Information about the material itself is not modified, but it can create confusion for designers.
The export from TEKLA is also executed via the direct link, which requires installing the additional Robot Link application (version 1.56 used). After verifying the analytical model, the transfer is performed without further user intervention, similarly to REVIT. In the case of the hall structure, the following are preserved: geometry, materials and characteristics of all profiles except for the bracing bars. Figure 6 shows a fragment of the hall model's side elevation obtained in ROBOT from REVIT (left) and TEKLA (right) software. The red dots mark the nodes generated after the model transfer. As a result of the REVIT-ROBOT transfer, they are created in the correct positions. In contrast, after the TEKLA-ROBOT transfer, excessive nodes are visible in all of the bar intersections. Before proceeding with the FEM analysis, these nodes must therefore be eliminated, and the loads must be redefined, their combinations created, and the type of elements and their offsets verified. The direct transfer of the model of the reinforced concrete structure from TEKLA to ROBOT is also correct, although the elements originally constructed from ready-made components (stair flights) are not present in the analytical model, so their transfer is also not possible. The loss of previously defined loads occurs similarly to the data transfer for the steel hall. On the other hand, if connections or characteristics of concrete elements (including surface panels) are typical, the transfer itself does not interfere with such information and thus does not modify the obtained model. The effect of transferring of both models from TEKLA to ROBOT is almost identical to the one demonstrated one in Fig. 5.

Data transfer to RFEM
The data transfer from REVIT to RFEM is carried out using the REVIT-Dlubal Link plug-in. It is also possible to transfer in the opposite direction, similarly to the REVIT-ROBOT transfer. Furthermore, this plug-in enables users to save the model in the native RFEM format *.rf5. The exported geometry of the models is correct in both cases. For example, the steel hall model retains the rotated purlins' orientation, and the wall panels of the elevator shaft in the reinforced concrete structure model have been divided accordingly as in the original. The transfer's results can be seen in Fig. 7. On the other hand, material data is lost. Young's modulus or thermal expansion coefficient do not have assigned values, even though the material names and the corresponding self-weight (dead load) are transferred unreservedly. Incorrect definitions of hall bracing profiles are also an issue. The transfer back to REVIT in both cases does not generate additional errors, which means that the REVIT-RFEM-REVIT coupling allows the models to be modified and updated efficiently. Another possibility is the transfer using the IFC format, using the IFC2x3 specification to be more precise (for more information, see [18], [19], [26]). The steel hall's exported model is of very poor quality, as is shown in Fig. 8. In spite of many attempts to fix the performance of this export, e.g. by installing the current version of IFC 2020 application for REVIT, the resulting model is not suitable for further analysis and its correction according to the whole list of errors would take more time than creating the model from scratch in RFEM itself. Fig. 8. View of steel structure model in RFEM after exporting it from REVIT using IFC format RFEM offers several possibilities to import files of different types (see the dialogue box in Fig. 9). The transfer of models from TEKLA has been tested in several alternative ways. The first one is a direct link. In addition, RFEM provides the choice to import based on an analytical or a physical model. The correlation of versions of the software from source to target is also important -TEKLA's version is 2019i SP2, RFEM's version is 5.21.02. The import of models via Direct Link varies depending on the structure type. For a steel hall computational model obtained from an analytical model, the information is transferred without major errors. The problem is the newly created nodes where the bracings intersect, as is the case with the TEKLA-ROBOT transfer (see Fig. 6 on the right). The model also failed to recognise pipe shapes, despite the aptly detected HEB or IPE cross-sections. If the physical model is the base, then instead of correct definitions of supports, there are foundation feet as redundant elements in the hall's computational analysis. In case of a reinforced concrete structure model imported on the basis of the analytical model, practically all of the information is transferred correctly: geometry of elements, their connections, concrete classes or cross-sectional characteristics of individual beams, columns, floors and walls. The exception is the lack of walls with openings in the lift shaft and the lack of loads for some surfaces of floor slabs. A completely different effect is obtained from the transfer using the physical model. The structural elements have no common nodes. The position of one of the walls is shifted down the foundation. The whole model is unstable and requires accurate tracing and introduction of corrections so that further analysis (e.g. static FEM calculations) is possible. However, it may be too expensive to carry out such a correction, despite the properly provided information on profiles or concrete type. For steel structures, an additional way of data transfer to RFEM is possible, i.e. via formats CIS/2 (an acronym for CIMsteel Integration Standards) or DSTV (an acronym for Deutsche Stahlbau-Verband). The model is saved as an ASCII file (American Standard Code for Information Interchange), so it is quite easy to verify its contents. The model of the hall generated by the CIS/2 standard contains an acceptable number of errors: excessive nodes are created, the rotation of the purlins is interpreted in the opposite direction than intended, and the pipe profiles are not recognised, although correct names are assigned. Hence, the resulting model needs to be corrected, albeit is still feasible. If the transfer is carried out using the DSTV format, then the received model is nearly error-free, except for some profiles having incorrect labels. This type of transfer is therefore preferable. The model carried by DSTV is shown in Fig. 10. Fig. 10. View of steel structure's model in RFEM after exporting it from TEKLA using DSTV format As a last possibility to transfer the model from TEKLA to RFEM, the 2x3 IFC format is used. Before performing the transfer in TEKLA, it is worth noting that it is crucial to define the type of the structural elements as a transferred IFC attribute. Based on this attribute of the element, RFEM automatically decides whether the element is structural. An incorrect assignment of this attribute can result in its deletion from the computational model. In both cases of structures, the resulting models cannot be applied for further analysis. For example, the hall model contains extra nodes, as well as cross-sections, which are not recognised. Shortcomings of the exported model of the reinforced concrete structure largely coincide with disadvantages known from the direct export based on the physical model. The effect of this transfer via the IFC2x3 file format is illustrated in Fig. 11. The structure is not complete. There are zero values of all material characteristics. The adaptation of both models from the versions obtained directly from the transfer via IFC to the versions ready for further analyses is not worthwhile because of the time effort involved. Fig. 11. View of reinforced concrete structure's model in RFEM after exporting it from TEKLA using IFC format

Data transfer to SCIA
The third target program in which FEM computations can be performed is SCIA. The first discussed transfer is operated via the plug-in called CADS Revit SCIA Engineer Link. Once it's installed to REVIT, the user can access a tab and the dialogue box presented in Fig. 12. The export is based on an automatically generated analytical model and preliminary definition of some information, e.g. design standard. Data transfer is saved as a *.r2s file recognised by SCIA. During the transfer of the truss hall construction model, the process is interrupted, and the user has to map the type of materials and sections which are not automatically detected. It is possible to skip the step of "manual" mapping during the transfer, but this results in the loss of some information, e.g. the material is remembered as "Unknown". The mapping of certain model features is both a disadvantage and an advantage. For small structures, it can provide a point of verification and guarantee that the resulting model is correct, but for very large structures (with thousands of different structural elements and their attributes), this activity can turn out to be too time-consuming. The application of this plug-in also offers the possibility to transfer in the opposite direction, whereby REVIT again requires to map the unrecognised model characteristics when importing. Figure 13 depicts models of the steel hall and the reinforced concrete building in SCIA. The export process for the model of the reinforced concrete structure is identical -the user has to enter the material data and some profiles by himself, thus mapping the relevant information is needed. A re-transfer is possible in the same manner. In summary, the REVIT-SCIA plug-in provides good results, and the process of information mapping replaces correction of the exported model.
An alternative approach may be to employ the IFC2x3 format for transfer. Similar as in the previous cases, the use of the IFC standard results in a model that is not suitable for further analysis due to too many required corrections, e.g. for the trusses of a steel hall, the bottom and top chords are detected as "generic solids" without any additional properties. Overall, the IFC transfer produces a much better model in SCIA than in RFEM, but inaccuracies in the geometry (e.g. position of nodes) and missed information concerning materials or profiles, eliminates this type of transfer from further analysis. The transfer of the reinforced concrete structure model using IFC from REVIT to SCIA has not been analysed. Although the SCIA-Tekla link plug-in exists and allows to generate an *.s2t type file, the versions of the programs used in this paper do not allow the use of this tool. The possibility to export the steel structure using IFC2x3 format is briefly described below. An adaptation of the resulting model is possible, but the number of necessary corrections is quite expensive in terms of time. Hence, using the IFC standard produces a model, which has the correct structural configuration and correct cross-sections, but it requires material definitions or, e.g. "tightening" of the position of nodes where they connect. If comparison of transferred models is limited solely to those obtained with the IFC format, the TEKLA-SCIA data transfer, although with the loss of some important information, gives the best output via IFC among all the variants presented in the paper that employ this standard.

FEM static analysis of steel hall girder -model comparison
For further comparison of the quality of the transfers, a simple FEM analysis (fundamentals of the Finite Element Method -for more see, e.g. [27]- [29]) is carried out in each target program, limited only to the static calculation of the steel hall and one load case. The model in ROBOT is obtained via the direct link with TEKLA. The structure analysed in RFEM is derived from the physical model originally built also in TEKLA. Computations in SCIA are performed based on the model being transferred by the plug-in from REVIT. A typical, uniform and linear load applied to the purlins of the roof slopes along the hall is employed. The analysis is valid for the whole structure, but the results presented below refer only to a selected truss girder. Figure 14 depicts the diagrams of axial forces N in bars for the selected module of the structure determined in all three calculation programs. Figure 15 shows    Tables 2-5 summarise all the transfers demonstrated in the paper. Table 2  In addition, the sign * is used to indicate that the resulting model cannot be further analysed, and the sign ⁑ character is used to indicate that the computational model needs to be adjusted if it employs components that aren't created in the analytical model. When a +/-sign appears in the table, it means that certain information is partially transferred. For example, the REVIT-RFEM transfer using the plug-in for the hall model (see the third row in Tab. 2) transfers the geometry correctly, but it does not transfer the material data and it causes an issue when the data for some profiles is moved improperly, in this case -for bracings.   It should be noted that the paper omits data transfer between TEKLA and REVIT, where in both programs the use of the Export to Revit Geometry plug-in as well as the use of the open IFC format is effective. Moreover, a successful transfer is possible in both directions, possibly by mapping of some model attributes, e.g. profiles or materials.

Conclusions
The paper verifies available data transfers for two typical structural models between selected modeling and computational analysis software. The first object is a model of a steel industrial hall. The second object is a reinforced concrete residential building. Both models are created in Autodesk Revit 2020 [12] (REVIT) and Tekla Structures 2019i [13] (TEKLA). The target programs in which FEM calculations (e.g. static) can be performed, are: Autodesk Robot Structural Analysis Professional 2020 [14] (ROBOT), Dlubal RFEM 5 [15] (RFEM) and SCIA Engineer 20 [16] (SCIA).
When using the Direct Link transfer, the resulting models generally correctly reflect the structural layout, which can be subjected to further computational analysis. The usage of plug-ins has a similar effect and also leads to models that require relatively minor corrections. However, attention should be paid to the fact that in the source programs (REVIT or TEKLA), the corresponding model components are created so that they are visible in the analytical model. Then the model is immediately applicable for further use, such as in the transfer REVIT-ROBOT. Thus, a correct analytical model is usually the starting point for the proper performance of data transfer. The ability to transfer models efficiently can speed up the work of design offices. It is also possible to exchange data between different equipment (two different computers, servers or tablets). Another variant of data transfer is via so-called open formats. They differ from native formats because their structure should be available in commonly used software. For this purpose, formats of two different types have been studied: dedicated and fully open. CIS/2 and DSTV type files are specifically intended for the transfer of steelwork models, with the DSTV format producing better results. An alternative way is to transfer via an open IFC file. As shown in this article, the effectiveness of transferring models via the IFC format is rather poor since the resulting model is not even suitable for further adjustment in order to prepare it for calculations. The transfer TEKLA-SCIA is an exception because the obtained model can be adapted for further FEM analysis.
The possibility of data transfer (interoperability) of AEC software, i.e. programs dedicated for architect and structural designers, provides a basis for effective inter-branch cooperation in design offices, regardless of their location in the world. The reason of less fruitful collaborations are rather limitations of hardware and resources of the software itself in individual offices. Therefore, despite the difficulties presented in the article, it is worth popularising and developing the use of transfer via open formats such as IFC. All the more so, as open standards may in the future become the primary tool for communication between engineering software from different producers in the world. Depending on the components used during modeling and the level of complexity of the objects, the appropriate type of transfer can be selected. This paper discusses the different degrees of correctness for the transfer of models and their possible repair requirements after they are exported. As shown, the best data transfer can be achieved by direct link or by using a plug-in. Based on the comparisons and observations made in the paper, the designer can evaluate the available tools and make a decision regarding the need to use transfers between programs, as well as the cost of time-consuming model corrections in the context of own skills.