Calculation and representation of structural reinforcement in Building Information Models using Revit Structure and SOFiSTiK

Transcription

1 Technische Universität München Faculty of Civil Engineering and Geodesy Computational Modeling and Simulation Group Calculation and representation of structural reinforcement in Building Information Models using Revit Structure and SOFiSTiK José Manuel Solís López Master s thesis for the Master of Science program Computational Mechanics Author: José Manuel Solís López Matriculation number: Supervisor: Prof. Dr.-Ing. André Borrmann Date of issue: 01. August 2011 Date of submission: 21. December 2011

2 Involved Organisations Computational Modeling and Simulation Group Faculty of Civil Engineering and Geodesy Technische Universität München Arcisstraße 21 D München Declaration With this statement I declare, that I have independently completed this Master s thesis. The thoughts taken directly or indirectly from external sources are properly marked as such. This thesis was not previously submitted to another academic institution and has also not yet been published. München, December 15, 2011 José Manuel Solís López José Manuel Solís López Haymann Str. 6 D Oberschleißheim manuel.solis.lopez@googl .com

3 Abstract The 3D visual objects are very useful to improve the understanding of technical documentation and descriptive specifications. However, the representation of structural reinforcement in concrete structures has been relegated to bidimensional graphics, even if the structure itself is modeled in three dimensions. Nevertheless, creating a 3D reinforcement model is not a trivial task, since it has to be incorporated in the structural design phase of the building process. In this context, the combination of Revit Structure and SOFiSTiK shows many advantages to complete the structural design in a BIM environment. By means of Revit Structure, a 3D reinforcement model can be generated; besides, the 3D visualization can be enriched significantly through the multidimensional data scheme established by the BIM concept. In this way, the critical issue in the Revit-SOFiSTiK Workflow is the exchange of information between both software packages, i.e. the interoperation capacity. Currently, the SOFiSTiK extensions for Revit Structure are able to export data from Revit to SOFiSTiK, however the link is unidirectional and the data network cannot retrieve information from SOFiSTiK to Revit. Therefore, in order to improve the interoperability between the software in question regarding the structural reinforcement, the Revit.NET API was implemented to develop an application i.e. 3DReinforcement with the capacity to read the SOFiSTiK database and to map this raw data to an equivalent 3D reinforcement model. Likewise, the alternative of a 3D representation of reinforcement enriched with metadata in PDF format is explored in order to offer a variant to integrate the documentation of the project. The PDF files are a convenient option to exchange information, since this data format is commonly used almost everywhere and it allows a live interaction of the user with the reinforcement model in order to improve the understanding of the 3D objects description, i.e. the specifications of the reinforcing bars. Summarizing, this work presents an approach to link SOFiSTiK and Revit in order to create a 3D reinforcement model, which can be also used to produce a 3D PDF document. The solution is synthesized in an application based on the Revit API, i.e. 3DR, which is integrated in the Revit-SOFiSTiK workflow.

4 IV Contents Abstract Contents List of figures List of tables List of Code Regions Nomenclature III IV VII XI XIII XIV 1 Introduction Background Scope of the project Project limitations Outline Instructions for reading Fundamental concepts Building Information Modeling - Basic Concept Historical overview Structural Building Information Modeling BIM interoperability Autodesk Revit Structure Data structure in Revit Families, types and elements Structural modeling Structural analytical model SOFiSTiK General description SOFiSTiK Extensions for Revit Structure SeRs description Results using SeRs Limitations and Restrictions of SeRs Reinforcement in Revit Structure Placing reinforcing bars Area reinforcement Path reinforcement Structural detailing Revit Extensions for Reinforcement Revit extensions Description Results using Revit Extensions Limitations and Restrictions of the Revit Extensions

5 2.5 Revit.NET API Basic technology Application structure IExternalCommand IExternalApplication Transactions Database organization Elements Parameters Filters Units in Revit Structure Structural Reinforcement Rebar elements Rebar types Hook types Materials D PDF documents PDF internal structure D models in PDF format Universal 3D file format Universal 3D Sample Software The movie15 L A TEX package D PDF from Revit Models DReinforcement: a Revit API implementation The application 3DR Basic technologies Workflow DR Outcomes A 3D reinforcement model in Revit Structure The reinforcement model in PDF format Integration of 3DR with the Revit reinforcing tools DR Structure DR internal process Working sequences in 3DR Set initial conditions Read the SOFiSTiK database Create the internal data structures Generate the Rebar Integrate the 3D PDF interface DR in the context of interoperability Limitations and restrictions of 3DR Delimitation of the applicability of 3DR Compatibility with the new software releases

6 4 Use cases D reinforcement models and their applicability Isolated elements D Frames D Structures Local reinforcement generation The alternative 3D representation in PDF format Limitations of Revit Structure regarding the reinforcement representation Conclusions Sub-conclusions Chapter 1: Introduction Chapter 2: Fundamental concepts Chapter 3: 3DReinforcement: a Revit API implementation Chapter 4: Use cases Final remarks Outlook Bibliography 116 A Structural detailing in isolated elements 119 A.1 Simply supported beam A.1.1 Design parameters A.1.2 Structural Details A.2 Isolated column and foundation A.2.1 Design parameters A.2.2 Structural Details B Structural detailing in 2D frames 126 B.1 Design parameters B.2 Structural Details C Structural detailing in 3D structures 131 C.1 Design parameters C.2 Structural Details D Local structural detailing in 3D structures 140 D.1 Design parameters D.2 Structural Details Index 146

7 VII List of Figures 1.1 Phases of the building process with emphasis in the sub-phases of the structural design stage. [Nielsen and Madsen(2010)] Workflow between SOFiSTiK and Revit Structure. The dashed lines represent the points under current development The Building Information Modeling (BIM) process Development time line of CAD and BIM systems Comands in Autocad Back in 1985 one could memorize all the commands as they were about 5% of the commands today buildingsmart Logo Left: BIM (model). Right: SBIM (model). Note that this is a very simple example, where only a fewloads and centre lines are shown. [Nielsen and Madsen(2010)] Static analysis of a Beam using Revit Extensions Industry Foundation Classes on Revit Structure Type properties in Revit Structure. The parameters Breite (width) and Höhe (height) define the dimensions of the beam Data structure in Revit for a project with 3 levels. The elements must always belong to a level Category, family and type from a beam element with ID= Joining of concrete beams and columns. Visually the central beam is trimed but its definition parameters have not changed Analytical and physical Model of a simple bridge formed by a concrete girder slab and its respective rectangular Piers Top: Analytical model without any modification, note the discrepancy in the connection points of the beams. Bottom: Corrected analytical model SOFiSTiK structure SOFiSTiK tools bar placed on the additional modules tab of Revit Structure SeRs exporting GUI Set of files created by SeRs and Revit project

8 2.18 Top view of the testing slab. [Fingerloos(2011)] Structure analysed with SOFiSTiK. The load case is the one created on Revit for the self weight Structure exported using the SOFiSTiK extensions, including loads and boundary conditions Set of beams with the same type but different rebar shapes Rebar created on a set of beams and a colum In order to create correctly a set of longitudinal reinforcement for the shown beam, the green plane has to be selected as a reference for the rebar Rebar set on a column. The complete group was create based on two single bars Area reinforcement in a section view Detail of an isolated footing created in Revit Structure Revit extensions GUI used to set the parameters for generating rebar in a beam Structure selected to test the Revit extensions Reinforcement in a slanted beam. Note the error in the stirrups distrubution Reinforcement in a wall and its footing. Note the interferences between the rebar placed in the corner Reinforcement generated with the Revit extensions around an opening in a slab Structure of a PDF document. [Adobe Systems Incorporated(2006)] D representation of a Icosahedron Structure of a IDTF file Process of the 3DR application in the contex of the Revit-SOFiSTiK workflow The process of the 3DR application. The dashed lines denote the optional sections Set of reinforcement bars created by 3DR in a beam. Note they are grouped under the name: Rebar The process to create a PDF document for the reinforcement model using 3DR D Reinforcement model of a Beam generated with 3DR Organization of the information flow in 3DR by means of the internal data structures Projection of critical points to generate virtual faces on a beam element Meshing of a longitudinal rebar to be included in the IDTF model

9 3.9 Mapping of the SOFiSTiK data into the corresponding Revit objects by means of 3DR Interoperability between SOFiSTiK and Revit Structure through the 3DR virtual interface D reinforcement in a isolated beam D reinforcement in a isolated Column and 2D section view Sectional view of 3D reinforcement in a continuous beam supported by a set of columns D reinforcement in a connection point of a 2D frame Detail of connection in a 3D structure D Reinforcement model writen in U3D format D reinforcement generated locally on a connection point D Reinforcement model writen in U3D format Properties of 3D rebar and model tree in a PDF reinforcement model A.1 Simply supported beam with a under the action of a line load A.2 Top view over the simply supported beam on question A.3 Section view over axis A.4 Cross section of Beam on axis A.5 3D reinforcement in a isolated beam A.6 U3D Reinforcement model of a Beam generated with 3DR A.7 Left:Isolated column and foundation. Right: equivalent SOFiSTiK model A.8 Cross section of the Column on question A.9 3D reinforcement in a isolated Column and 2D sectional view A.10 Detail of foundation under isolated column B.1 Continuous beam and equivalent SOFiSTiK model B.2 3D reinforcement in a continuous beam supported by a set of columns B.3 Sectional view of 3D reinforcement in a continuous beam supported by a set of columns B.4 Top view of continuous beam B.5 Standard cross section of the beams which integrate the 2D frame

10 B.6 3D detail of foundation under a column B.7 2D detail of connection between the beams and a supporting column B.8 3D detail of connection between the beams and a supporting column C.1 Analytical model and load system on 3D structure C.2 Bending moments M y calculated by SOFiSTiK C.3 Shear forces V z calculated by SOFiSTiK C.4 Top view of 3D structure C.5 Standard cross section of the beams which integrate the 3D structure C.6 Sectional view of 3D reinforcement in x direction C.7 2D detail of connection point between two beams and one column C.8 3D view of connection point between two beams and one column C.9 2D detail of foundation under a column C.10 Sectional view of 3D reinforcement in y direction C.11 2D detail of connection point between a beam and a column C.12 3D reinforcement model of the entire structure D.1 FE model generated in SOFiSTiK D.2 Bending moments M y calculated by SOFiSTiK D.3 Top view of 3D structure D.4 3D reinforcement generated locally on a connection point D.5 Isolated elements of 3D reinforcement generated locally on a connection point. 144 D.6 3D local detail on a connection point D.7 U3D Reinforcement model of a connection generated with 3DR

11 XI List of Tables 2.1 3D solids and BIM model. The properties of the geometrical entities are included in in the BIM elements Three different link Types to set interoperability Base Units used by Revit Available diameters on the 3DR environment A.1 Parameters in relation to the properties of the element A.2 Load system applied on the element A.3 Material properties of the host element A.4 Material properties of the Reinforcing bars A.5 Parameters in relation to the properties of the element A.6 Load system applied on the element A.7 Material properties of the host element A.8 Material properties of the Reinforcing bars B.1 Load system applied on the elements B.2 Parameters in relation to the properties of the beams B.3 Parameters in relation to the properties of the columns B.4 Material properties of the host element B.5 Material properties of the longitudinal reinforcing bars B.6 Material properties of the transversal reinforcing bars C.1 Parameters in relation to the properties of the beams C.2 Parameters in relation to the properties of the columns C.3 Material properties of the host element C.4 Load system applied on the elements C.5 Material properties of the longitudinal reinforcing bars C.6 Material properties of the transversal reinforcing bars

12 D.1 Parameters in relation to the properties of the beams D.2 Parameters in relation to the properties of the columns D.3 Material properties of the host element D.4 Material properties of the longitudinal reinforcing bars D.5 Material properties of the transversal reinforcing bars D.6 Load system applied on beams D.7 Load system applied on columns

13 XIII List of Code Regions 2.1 Structure of a *.addin file Usual location of Addins in Windows XP Code used to define the Framework version; this can change depending on the configuration of each system Implementation of an External Command Implementation of an External Application Transaction s structure Edit parameters by direct access (bottom) and parameter set (top) Filter applied in order to store in the List element x all the concrete beams and columns contained in the selectedids set Generic method to create a new element Implementation of NewRebar(... ) method to create rebar Creation of a new rebar type. Note the multiplication of the assigned values in order to have the correct units Method to create a new steel Material Method implemented to find all the concrete and steel materials contained into the Revit project Metadata text block in a IDTF file L A TEX code used to embed a 3D object L A TEX Structure of a predefined view for a 3D PDF file Global structure of 3DR as an External Command Pseudo-code which ilustrates the application process of 3DR Struct used to store the description of nodes written according to the help file CDBase.chm Method implemented to retrieve the data about a single node. Note that an auxiliary fixed pointer is needed to complete the operation Functions implemented by 3DR to manipulate the SOFiSTiK database The IDTF writing process illustrated by a pseudo-code

14 XIV Nomenclature 3DR A&D AEC API B-rep BIM CAD CFD CLR CSG DBV DLL ECMA FE FEM GUI GUID IDTF IFC MEP OOM OOP PDF PRC Rebar RGB 3DReinforcement Analysis and Design Architectural, Engineering and Construction Application Programming Interface Boundary Representation Building Information Modeling Computer Aided Design Computational Fluid Dynamics Common Language Runtime Constructive Solid Geometry Deutscher Beton-und Bautechnik-Verein Dynamic Link Library European Computer Manufacturers Association Finite Element Finite Element Method Graphical user interface Globally Unique Identifier Intermediate Data Text File Industry Foundation Classes Mechanical, Electrical, and Plumbing Object-Oriented Modeling Object Oriented Programming Portable Document Format Product Representation Compact Reinforcing bars Red, Green, Blue additive color model

15 RIP SBIM SeRs SI SSD U3D Raster Image Processor Structural Building Information Modeling Sofistik Extensions for Revit Structure International System of Units SOFiSTiK-Structural-Desktop Universal 3D VS2010 Visual Studio 2010 XML Extensible Markup Language

16 1 CHAPTER1 Introduction 1.1 Background The use of reinforcement steel in concrete structures is very common in the AEC industry, hence it helps to carry tensile loads, reduce the displacements in a long term, increase the ductility, reduce cracking and improve much more characteristics of the simple concrete. Therefore including reinforcement in the different instances of the project can be considered as a basic task in the production of building virtual models. [Maunula(2008)] Traditionally the representation of reinforcement has been included in the structural design phase of the building process; more specifically this is developed during the detail design stage. Hence the reinforcement is generated according to the specifications and characteristics of the conceptual model and it is not a constitutive part of it [Nielsen and Madsen(2010)]. Figure 1.1 illustrates the traditional building process and its different phases. Program Structural Design {...} Construction Operation Demolition Structural Design Conceptual Design Detail Design Figure 1.1: Phases of the building process with emphasis in the sub-phases of the structural design stage. [Nielsen and Madsen(2010)] As usual in the AEC industry, the final product of the reinforcement design is a set of 2D drawings in which the specifications of the rebar are presented and described. Thus the reinforcement has been relegated to 2D representations because of two main reasons: on the one hand, the AEC industry does not have a readiness for the changes, which is why the evolution of the sector is slower than in other similar industries; and on the other hand, the huge challenge that implies generating hundreds of reinforcing bars which have to correspond to the results of the analysis and design process.

17 1.1. Background 2 However with the growing implementation of the 3D and BIM technologies, a total new universe of possibilities has appeared to bring the reinforcement representation to a new level of development. Applying the concept of BIM allows a total integration of the different sectors involved into a building process, said differently BIM brings the virtual models to a new dimension where the information flows freely and the data is on a constant development. Nevertheless integrating the reinforcement to the BIM process implies solving several complex issues, such as: Defining the properties and attributes of the rebar. Developing the required interoperability tools to link the different software packages used for the analysis and design of the rebar. Calculating the number of the required reinforcing bars and its dimension. Establishing relations between the rebar and its corresponding host elements. Integrating the output products which truly exploit the potential of the 3D model. Nowadays there are several applications which assist the BIM process, one of them is Autodesk Revit Structure. This software implementation is focused on the field of structural design and provides a wide range of computational tools to create a 3D model of a building, including specific functions for the generation of three dimensional reinforcement elements. Furthermore, one of the most remarkable characteristics of Revit Structure is that the users can extend the capabilities of the program by means of the Revit Application Programming Interface (API), thus new functions, algorithms and tools can be developed in order to solve specific tasks that were not considered originally by the developers or to improve the existing ones according to the particular requirements of a project or an user. So then, Revit Structure can be considered as a very promising platform to develop a virtual model of the building on a BIM environment, this including the reinforcement of the concrete elements. However Revit Structure only offers solution for the problems related to the structural design but the mechanical analysis of the structure is missing. In order to complete the process a Finite Element software package with the capability to be integrated with Revit Structure has to be implemented; again there is more than one possible option in the market, but in this thesis the program SOFiSTiK was selected. The synchronization between SOFiSTiK and Revit Structure is achieved through the SOFiSTiK Extensions for Revit Structure; this is a complement for Revit Structure written using the Revit API which allows to exchange data from Revit Structure to SOFiSTiK. In this manner, by means of the correct application of Revit Structure and SOFiSTiK, a 3D virtual model of building containing the respective reinforcement can be created. Considering that the link between both programs is working only in one direction and the generation of the reinforcement has to be done manually, nevertheless the Revit API offers the possibility to handle with this task in a more efficient way, since this basically gives the chance to interact with the model to create, edit and delete the constituent elements of the project. This master s thesis focuses on the evaluation of the capabilities of Revit Structure to represent 3D reinforcement, putting special attention on the huge potential of the Revit API

18 1.2. Scope of the project 3 applied to this specific field. Likewise the integration between Revit Structure and SOFiSTiK is a fundamental part of the work, since all the rebar elements generated during the study are based on the results of FE analysis completed with SOFiSTiK. 1.2 Scope of the project The master s thesis project is based on the Revit-SOFiSTiK workflow concept for the integration of both programs, which is presented in the Figure 1.2. The SOFiSTiK extensions for Revit Structure allows exporting the data contained in the Revit model in order to create an equivalent model in SOFiSTiK; once the new database is created, all the capacities of SOFiSTiK can be used over it in order to complete successfully the structural design of the model. However the link is not bidirectional and there is not a communication channel in the direction SOFiSTiK-Revit. Revit Structure Model elements SOFiSTiK Extensions SOFiSTiK FE analysis Descriptions and Quantities Applied static system Revit API 3D PDF Structural design Documentation Figure 1.2: Workflow between SOFiSTiK and Revit Structure. The dashed lines represent the points under current development. Therefore this thesis is concentrated in creating an alternative for this missing link in order to achieve the generation of 3D Reinforcement models founded in the SOFiSTiK calculations. Thus the basic idea about the 3D representation of reinforcement consists in the next steps: 1. Generate the structural model with Revit Structure. 2. Export the model to SOFiSTiK. 3. Analyze the structure and perform the structural design. 4. Read the results of the design and create the corresponding structural reinforcement in Revit Structure by means of the Revit API.

19 Project limitations 4 5. Additionally, the option of generating a 3D PDF from the Revit Reinforcement model is evaluated. Furthermore, the SOFiSTiK extensions for Revit Structure are a point of the research since they are a constitutive phase of the working line established previously. In the same manner the basic tools available in Revit Structure to generate 3D reinforcement are considered in this study because they are the only available functions to create structural reinforcement and the Revit API just applies them following the given instructions. Hence a detailed documentation of the restrictions and limitations of Revit Structure with respect to the 3D representations of reinforcement is developed along the project Project limitations Since the concept of 3D reinforcement is quite a broad subject, the limitations of this project have to be stated. In the following the specific restrictions and limitations of the thesis are mentioned. The evaluated software packages correspond to the following versions: Revit Structure 2011 and SOFiSTiK The investigation is concentrated on simple elements and only simple connection points. Complicated connections are out of scope. The Revit API based application that was developed for this thesis is focused on these simple cases, just in order to prove the capacities of the API. The 3D PDF documents, which are generated using the Revit API, are limited to the reinforcement model and the corresponding host elements. 1.3 Outline The first part of this master s thesis is formed by an introduction. The rest of the study is organized as follows: Chapter 2: Fundamental concepts. This Chapter introduces the basic technologies and concepts applied in the development of the project. Besides it depicts the basic tools offered by Revit Structure and SOFiSTiK concerning the field of the 3D reinforcement. Chapter 3: 3DReinforcement: a Revit API implementation. The development process of a Revit API program oriented to the generation of 3D reinforcement using the results of a FE analysis performed on SOFiSTiK is described here. The solutions of some critical tasks are explained in detail in order to illustrate how complex problems can be reduced to simple implementations of commands by means of the API. Chapter 4: Use cases.

20 1.4. Instructions for reading 5 The Chapter 4 is evoked on the description of the results that can be obtained using the different tools offered by Revit Structure, including the 3D Reinforcement application depicted in the Chapter 3. In this way, by means of practical examples the final results of the project are illustrated. Chapter 5: Conclusions. In this Chapter the concluding remarks about the capacity of Revit Structure to represent 3D reinforcement are summarized. 1.4 Instructions for reading For readers with knowledge in the field of BIM and experience with Revit Structure the Chapter 2: Fundamental concepts, would not be very relevant, since it provides basic concepts and terms that are implemented later. However some important tools, such as the SOFiSTiK extensions for Revit Structure and the Revit.NET API, are described here, therefore the reader should be careful about starting the reading from Chapter 3. The Chapter 4 can be considered such as a collection of 3D representations of reinforcement in Revit Structure, consequently its reading could be done independently on the previous Chapters if the background of the applied tools is not in the interest of the reader.

21 6 CHAPTER2 Fundamental concepts This Chapter gives a general overview about the fundamental concepts used in this thesis. The starting point is the basic definition of Building Information modeling and it is followed with a brief description of the capacities and potential of the structural BIM software Autodesk Revit Structure, specifically in the field of concrete reinforcement. To complete the description of the technologies employed in the project, the Revit.NET API and 3D PDF file format are defined and depicted, this including a theoretical illustration further by some practical examples and applications. All these notions lead to the scope of the project. 2.1 Building Information Modeling - Basic Concept The concept Building Information Modeling (BIM) can be defined as a process, which starts with the generation of a 3D representation of an object with specific properties, continues with the establishment of relationships in between the different components of the model, and finishes with the manage and adequateness of the model to the requirements of the different instances involved in the project. Figure 2.1: The Building Information Modeling (BIM) process.

22 2.1. Building Information Modeling - Basic Concept 7 BIM is much more than a 3D model, BIM implies a whole process chain which integrates all the phases in the building process. During the development of this process chain a continuous flow of digital information occurs resulting in a common virtual platform for all the persons related to the planning, design, construction and operation of the building. The objective of this constant exchange of information is on the one hand allowing a better collaboration among the participants in the project, and on the other hand avoiding the redundant entering and calculation of data, such as areas, volumes and material properties. [Seifert(2008)] 3D representation Points Lines Faces Solids BIM Element Element ID <Unique ID> Element type <Structural type> Material <Material type> <Material properties> Geometry <3D representation>... Table 2.1: 3D solids and BIM model. The properties of the geometrical entities are included in in the BIM elements. The most important concept in BIM is that each element of the model is not any more just a geometric representation of a physical entity but a virtual object with parameters that define it, these parameters can be since geometric information, spatial properties and mechanical characteristics until construction stages, costs and appearance preferences. The final result of a BIM process is an object oriented model which can be used during the whole lifecycle of the building, including its demolition, by different kind of professionals sharing information and knowledge between different working teams. [Robinson(2007)] Looking at the fact that we can define our own properties in a BIM model, it implies directly that we are not restricted any more to the 3 dimensions of the geometry representation. In other words, a BIM model is an nd model; in the architectural, engineering and construction (AEC) industry the fourth dimension is traditionally associated to the time schedules and construction stages and the fifth dimension is related to the economical aspects. In a self defined BIM model other possible dimensions are: Visualization of objects and detailing Structural calculations Documentation and description of objects Customer requirements

23 Historical overview 8 This quasi infinity number of model dimensions leads to many benefits and improvements in the whole process chain, increasing the efficiency and quality of the project. Moreover the advantages of using BIM could be reflected also in the interaction with the non-technical people (clients, users, etc.) by means of better visualization alternatives, the use of different simulation scenarios and the ability to take decisions and change the project to a lower price. [Ernstrom(2006)] To close this description about the concept of BIM is important to have in mind the next points: [Liebich(2011)] BIM is a process, hence BIM is more than software, it is an Idea and a whole production paradigm. BIM is not a new concept but it represents a digital revolution of the traditional perspective in the AEC industry. In order to use BIM in a more efficient way, every task in the production process must be included in the BIM schema, in other words, one does not use the full capacities of BIM if there is not a completed integration of the parts involved in the project. BIM implies a better planning, programming and cost control but also the developing of new skills to use and manage these capacities Historical overview Nowadays it is very common to hear about 3D modeling or Computer Aided Design (CAD), even for the people who are not directly related to the technical issues, the idea about a virtual model of a building is not something unusual. However, not long time ago this kind of topics were discussed just in the universities or by the research teams of few companies, during the latest 70 s the first commercial CAD applications appeared on the market, in this ages systems such as TriCad, RUCAPS, GINTRAN or GDS were the leading software packages. These applications were very expensive and some of them, like the case of RUCAPS, did not create a real 3D model, but a 2.5D representation in which the final model was created by means of a series of 2D views. TRICAD AutoCAD 1.0 ArchiCAD 3.0 Revit 1.0 Revit Structure First commercial CAD app. Software based on OOM IFC 1.0 SBIM software Figure 2.2: Development time line of CAD and BIM systems. Thus the standard in the industry was a big room full of people working in the drafting, another room for people working in the technical calculation, other one for the time scheduling

24 Historical overview 9 and so on. But this working structure, inherited from the 18 th century, started to change in the 80 s when the computers became a standard tool in the industry. The first release of AutoCAD appeared in December 1982, the functions and utilities that AutoCAD 1.0 offered were quite elemental but they allowed doing more than just represent points and lines, some tools like layers, text, blocks and dimensions were added and improved in the next versions. Maybe one of the most important improvements in the development of AutoCAD was the introduction of AutoLISP, a scripting language which allows independent developers to write their own applications on the AutoCAD platform. With this new capacity, the users were not restricted any more to the general utilities of the program but they could develop special tools to solve specific problems increasing the functionalities of the system. Figure 2.3: Comands in Autocad Back in 1985 one could memorize all the commands as they were about 5% of the commands today. During the 80 s and 90 s the growing and improvement of the CAD systems was constant and they became an essential element of the industry very fast, it is in this period when the fundaments of Object-Oriented Modeling (OOM) were established. The concept of OOM is the origin of BIM; in OOM each element of the model has properties and relationships such as element type, material and sectional properties, purpose of the element within the structure, etc. It was in 1987 when the first OOM software was released, Graphisoft introduced ArchiCAD to the market, for the original Apple Macintosh, and with this system a new phase started. However OOM cannot be considered 100% BIM because the model does not possess additional information relevant for the participants in the building process, for instance scheduling or structural loads. During the 90 s diverse companies developed their own BIM software, firms like Autodesk, Bentley systems or Tekla Structures realized the potential of this concept and did not let go the opportunity to innovate and explore into the BIM idea. The development process of BIM solutions was neither easy nor short; factors such as the computers capacity and the high costs did not help to make it faster, but in some specific sectors, like structural steel, the research and production of BIM tools grew up rapidly.

25 Structural Building Information Modeling 10 One big step in the development of BIM was the establishment of the Industry Foundation Classes (IFC) a effort to standardize the concept and the output format of the different BIM software, before this try there were similar ideas about BIM without a common concept, some examples are Virtual Building by Graphisoft, Bauteilorientiertes Arbeiten by Nemetschek AG and Integrated Project Models by Bentley Systems. [Suhr(2011)] Figure 2.4: buildingsmart Logo. In the year 2000 Revit 1.0, the first parametric building modeler specifically designed for the AEC industry, was released. With concepts such as synchronization of the documentation and life-cycle planning, Revit became a standard in the AEC industry. At this time BIM is not a new technology any more and the necessities of the users have led to the development of specialized BIM applications for the different industrial sectors, for instance the specific versions of Revit: Architecture, Structure and MEP Structural Building Information Modeling One can define Structural Building Information Modeling (SBIM) in a simplistic way such as the structural part of BIM. SBIM is a subset of BIM containing all the relevant information for the structural analysis and design of the Building, it can contain data about: [Hejnfelt and Oksengaard(2007)] Material properties Definition of cross sections Structural behavior Loads Load combinations Boundary conditions Geometry The reason to have separated models for the same project is on the one hand that usually much data present in the model is actually not necessary for a specific kind of professionals, and on the other hand sometimes they still need some particular information. For instance, an architectural model can contain elements like doors, rooms, overall decor or non structural walls, but these objects are not useful in the structural analysis and design process, moreover there is more information, such as loads and boundary conditions, that the architectural model does not have because they are only relevant for the structural engineers, thus a new model is generated in order to satisfy the special requirements of one sector of the industry.

26 BIM interoperability 11 Figure 2.5: Left: BIM (model). Right: SBIM (model). Note that this is a very simple example, where only a fewloads and centre lines are shown. [Nielsen and Madsen(2010)] However the SBIM model is not independent from other models, in general a SBIM model is based on the architectural model, there is an inferential relation between both models and the changes in one of them will be reflected on the other one. This constant interaction is one of the basic theses about BIM, different users working in the same model modifying it and sharing information between each other. It is here where the interoperability and the integration tools play a very important role. The final BIM model is produced by means of the combination of the architectural, structural and services models which contain some common information such as the geometry. Once the model is assembled, more dimensions can be added to it, e.g. time scheduling and budgeting. Some examples of SBIM applications are Tekla Structures and Autodesk Revit Structure; in this thesis this last program is implemented BIM interoperability The term interoperability refers to the ability of the BIM systems to exchange and update information in between the participants in the project. The use of open interfaces is fundamental in the BIM process; they allow having a fluent communication and customization of the model. For instance, in order to create a SBIM model one must obtain the data about the base geometry of the building from the architectural model; then aggregate information about the static system, structural elements, material properties and so on, which the architect did not define. When the SBIM model is ready, the analysis and design of the building has to be

27 BIM interoperability 12 made by means of an external program. Finally, the SBIM model must be updated with the results of the design. In this process at least one way of communication is needed between the SBIM system and the FEM software, likewise the implicit relationships between the SBIM model, the architectural model, the budget and the time schedule must be also satisfied. It is easy to see that the functionality and the efficiency of a BIM system depend directly on its interoperability and synchronization capacity. The quality of the communication flow is not a trivial issue and it can be an important factor in the selection of BIM software, factors such as supported objects, accuracy and bidirectional communication can be used to define the quality of the link. There are different ways to establish the interoperability, three technical ways to link two applications are: Add-on link, direct link and link through a standard format. In the following these techniques are described. [Hejnfelt and Oksengaard(2007)] Add on link BIM SBIM Add on Link through a standard format BIM SBIM IFC FEM Direct link BIM SBIM API FEM Table 2.2: Three different link Types to set interoperability. Add-on link. In this kind of link a plug-in software module is written over the platform of another application, the plug-in uses the information of the model to get some results (analysis and design) but at the same time it is dependent on the main application because the plug-in cannot work without the guest program. The Revit Extensions for Autodesk Revit Structure is a perfect example of this linking procedure. With this extension package it is possible to perform a structural analysis of beams, columns and frames without any external FEM software and use the results to generate reports and images. A relevant capacity of the Revit Extensions for this thesis is the generation of reinforcement. It is possible to generate standard reinforcement using this tool, but it does not take into account the loads and load cases, hence the

28 BIM interoperability 13 Revit Extensions can be considered as an instrument to improve efficiency of the manual rebar generation. The only way to get useful results using this extension package is with the help of the function Integration with Robot Structural Analysis ; in other words, using an external application. However in this case the plug-in is not more than an add-on link. [Autodesk(2010a)] Figure 2.6: Static analysis of a Beam using Revit Extensions. Link through a standard format. This link type basically consists on writing the file in standard format, in order to link two applications; both must be able to read this format. The two applications do not have any relationship and the quality of the link depend on the capacity of each application to interpret the file type. A very good example of this kind of link is the Industry Foundation Classes (IFC), which is an open file format created by buildingsmart (before International Alliance for Interoperability), i.e. a non-profit organization that enables data exchange and collaboration across the AEC industry. The IFC data schema comprises information covering the many disciplines that contribute to a building throughout its lifecycle: from conception, through design, construction and operation to refurbishment or demolition. [BuildingSMART(2011)] The basic idea behind IFC is that if everybody writes the data in the same way then everybody would be able to read it. The same source file is referenced by different software and different users, thus all the participants on the project can collaborate adding and updating the information on the base model, what is one of the objectives and fundaments of BIM. Generally a software application stores the data in a native and proprietary format (such as *.rvt for Revit Structure), then the user can generate and modify the model, but in order to exchange the information contained in the model, the application must write the file in the *.ifc format, thus the information is available to be read by another application. Additionally, for every implementation of an IFC exchange an Exchange

29 BIM interoperability 14 Requirement should be generated; the Exchange Requirement are organized in groups called IFC views and their main function is storing the information needed to be present in an exchange/sharing of data at a certain stage in a project. Figure 2.7: Industry Foundation Classes on Revit Structure. Unfortunately the development of IFC is not finished yet and, on the other hand, not all software needed in the construction process support this format, hence the use of it is limited. Direct link. In this case the connection between two applications is made through an open interface, i.e. Application Programming Interface (API). The API can use the functions and data present in the main application in order to get some results or transfer the information to another program by means of an intermediate result format. The direct link enables the interaction of the SBIM system with other software applications such as a FEM program. For instance in this thesis exactly this kind of link is used in order to export the data generated in Revit Structure to the FEM program SOFiSTiK. In this specific case the SOFiSTiK Extensions for Revit Structure generates a set of TEDDY files, i.e. a set of text files written in the SOFiSTiK scripting language which provides the necessary instructions to create a mapping of the Revit model in SOFiSTiK; including structural elements, cross sections, loads, support conditions and load cases. The resulting set of TEDDY files (*.dat) can be edited in order to improve it and finally is used to produce the model in SOFiSTiK where the process of analysis and design is made. [SOFiSTiK AG(2011a)] In order to complete a bidirectional link, limiting the case to reinforcement of concrete elements, the Revit.NET API was used to develop an application able to read the results of the design process from the SOFiSTiK database and then create the corresponding families and elements in Revit Structure. Another important functionality of the API written for this thesis is the capacity to create output files in 3D PDF format from the Reinforcement and its host element. All this will be described in detail in the Chapter 3.

30 2.2. Autodesk Revit Structure Autodesk Revit Structure Revit Structure is a Structural Building Information Modeling system for structural design and documentation. Revit Structure is based on BIM technology see Section 2.1 and can be used either to generate a new model or to modify one provided by another instance of the BIM process. Revit cannot be employed to make the structural analysis of the model, but it is possible using interoperability features (*.ifc files, API, etc.) exporting and updating the data of the project. Thus the capacities of Revit can be extended and improved, not only to make a FEM analysis, but to solve almost every other need of the BIM process. The base object in this application are the elements, which can be walls, columns, beams, slabs, etc. Besides the 3D geometry, these elements have properties and relationships with the surrounding elements, the properties can be abstract objects, e.g. supports, materials, construction phase; and they can be shared by several elements, such as a set of concrete beams with the same material. Figure 2.8: Type properties in Revit Structure. The parameters Breite (width) and Höhe (height) define the dimensions of the beam. Revit Structure can be considered as Object Based Parametric Modeling software, it means that the relationships among all elements of the model and their properties are enabled to change during any moment because they are not static but dynamic parameters. Each element in Revit Structure is defined according to a base class, such as the cross section of a beam or the path of some reinforcement bars, the geometry and properties of this base class

31 Data structure in Revit 16 is determined by arbitrary values, just to initialize it, and they have to be set up when one inserts the specific element into the model, however they can be modified at any time. The parametric operation of the software is a very essential characteristic of Revit Structure hence using this capability the program generates references between the elements and the database, thus an update of one variable can be applied to the entire model without making individual modifications on each element. Revit is designed to coordinate the changes into the model and to maintain data consistency; thereby Revit determines in real time any adjustment in the model and reflects it on every affected element. [Autodesk(2010b)] For instance, considering one beam with its respective reinforcement, if one changes the dimensions of the element it is not necessary to change the specifications for the reinforcement. Since it will change according to the new dimensions of the beam, because the parameters which define it, geometrically, are referenced to the host element. The same would happen when one changes the height of a floor, in this case the length of the linked columns would change automatically; or when we change the position of a beam, then all the joined elements would move together. Another basic concept about Revit is that all the model elements are attached to a reference plane. When the elements are generated, it is mandatory to do it on a working plane, e.g. a level or a grid line, then the created element will be linked to this plane and any change on it will affect the element as well. A good example of this feature is a column, usually the columns are referenced to a initial level and to a final level, thus the length depends on the height of the levels and if we want to extend the column we need to change either the height of the level or the reference to the level, pointing it to another one. [Leung(2011)] Finally, it is important to mention that Revit works by means of different design views of the model. Each view is independent and can be opened at the same time than other ones; Revit generates automatically some default views but the user can define his own views with the most convenient visual options. The changes made in one view are applied to the entire model immediately and they can be seen also in the other views without any refreshing process. [Autodesk(2007a)] Data structure in Revit The configuration of the data in Revit Structure corresponds to a hierarchical structure with several organization levels. The header of the structure is the project, which corresponds to the entire database. When a new model is created in Revit, in fact a new database and consequently a new project is created, all the information concerning to the model is contained here, including design views, relationships, element definitions and properties. Directly under the project position, we find a very important instance: the level. The level is an infinite horizontal invisible plane which can be used as a reference to place elements in the model. For example, in a standard building model usually one can define levels such as floors or foundation; there the elements, e.g. walls, slabs or beams, are placed and linked. Said differently, one adds structural elements to the corresponding floor like in a real construction process, creating the building level by level with the respecting model

32 Families, types and elements 17 elements. [Autodesk(2010b)] Model elements P r o j e c Level 1 Level 2 Level 3 Element properties Model elements Element properties Model elements Element properties Figure 2.9: Data structure in Revit for a project with 3 levels. The elements must always belong to a level Families, types and elements The working unit of the system is the element, in Revit Structure each virtual entity is an element and each element has a specific classification; there exists three grouping levels into the element classification schema, in descendent order they are: category, family and type. In order to illustrate it, one can think about them as a sequence of subsets, a specific category set contains several families and in turn every family into this category incorporates several types. The properties of the parent sets are inherited to the child ones and finally they are assigned to the model elements, in Revit Structure these elements are known as instances. Making an analogy to object oriented programming (OOP), an element is an object and it has a special type i.e. a class. In Revit Structure the base class is the category (column, wall, slab, etc.) and there are another two levels of derived classes (family and type) which inherit their attributes and behavior, such as in a classical hierarchical inheritance. The Revit objects i.e. the elements, can be converted among the different families and types but not from one category to another. For instance, a steel beam can be switched into a concrete beam but not into a wall or a column, this is a modification in the family; also the beam dimensions can be changed updating the type or creating a new one. In OOP this would be similar to change the data type of a variable, like when an integer value is transforming into double or string. However one has to consider that an object is more complex than a

33 Families, types and elements 18 Beam_ID Project structure Beams Reinforced concrete Beams RC 25 X RC 30 X 60 ID Steel Beams... Figure 2.10: Category, family and type from a beam element with ID= variable and a specific method has to be applied in order to complete the conversion; i.e. the change of the beam s material from concrete to steel does not consist only about changing the material itself, it implies also a change in the parametric definition of the beam, although some characteristics will remain, such as the length. There are two different types of model elements: model components and host elements. The main difference among them is that the first ones need a host element in order to be placed into the model. For instance, a window cannot be added to the model outside a wall; another example is a reinforcing bar, which is always linked to a beam or column and without this host element the bar cannot exist in the model. Furthermore placing elements in the model, another big task in the structural modeling on Revit is the generation of families and types, since generally the types are customized cases of a family, the families are the most important modeling tool. One should realize that the user is allowed to define its own families and types however the category set is fixed. There are 3 kinds of families in Revit Structure: [Autodesk(2010b)] Loadable families. This is the best example of user defined families, the geometry and the properties are fully assigned by the user and they can be stored in an external file in order to use them in other projects.

34 Structural modeling 19 System families. The system families are the predefined families in Revit Structure. They cannot be modified by the user, but sharing them is possible between different projects. They include the most common elements, such as walls or slabs, and can be used to create several element types to implement in the model. In-place families. This kind of families is useful when the user needs a truly unique element. They can be considered as a contradiction of BIM, because the parameters are constants values without any reference to other elements. They are allowed only to contain one single type. In order to use a similar object, it is necessary to replicate the family and change its properties Structural modeling The first step to create a SBIM model on Revit Structure is the generation of a new project, usually this task is made with the help of a structural template, a working frame which provides standard views with specific properties in order to allow the correct visualization of the structural elements. Another phase of this first step is loading structural families, Revit structure includes some default families which could be very useful for the modeling, but when the characteristics of the project turn more complex, self define customized families are needed. Once a new project is created different structural components can be added to the model. If the Revit catalog does not have a family which corresponds to our requirements, it is possible at any time loading new families, modifying the existing ones or generating them in an auxiliary view; one should not forget that the generation of new categories is not possible in Revit and the design process must be done according to this limitation. Some examples of element categories present in the system are: Structural columns Beams and beam systems Structural walls Foundation slabs and structural floors Trusses It is important to distinguish between structural and architectural components. Generally the architectural elements, e.g. columns or walls, share many properties with the structural ones but the last ones possess additional information relevant for the structural analysis and design such as an analytical model. Moreover, the structural elements have a special behavior because they join to other structural elements, for instance a set of beams would join to their respective supporting structural columns and successively these would join to some isolated foundations. The joining of elements is a remarkable characteristic because the geometry of the individual elements is modified according to their relation with the connected elements. The modification of the geometry does not mean a change in the parameters but in the topology and

35 Structural modeling 20 visualization options. In order to illustrate it, one can imagine a simple rectangular 2D concrete frame. In the points where the beams are connected to the columns, it would have an overlapping between them. This is not possible and the connection has to be either part of the beam or of the column. Thus the visualization on Revit would show a trimmed beam, however its parameters are not modified see Figure 2.11, said differently the beam is not cut. Figure 2.11: Joining of concrete beams and columns. Visually the central beam is trimed but its definition parameters have not changed. The joining also produces the automatic generation of control points in the geometry of the elements, what is very relevant whether we try to obtain it from an element in the model. These control points help for the visualization issues, thus two model elements would seem as one although they still are two well defined objects. The joins can either trim or extend the elements and the effects can be seen in real time on Revit. When the constitutive geometry of the faces from the boundary representation of the solids is accessed, this modified configuration is returned. When the elements are placed on the model by means of individual sketching, grid lines or any other method to introduce them, they can be modified using the advantages of the parametric representation, i.e. changing properties or updating types and families. Likewise model elements such as openings and reinforcements can be aggregated to the corresponding host elements, refining in this way the whole model. Some following tasks, such as the creation of output views, annotations and in general the detailing, can be very time consuming and are transcendental for the final result of the whole BIM process. Revit Structure offers several options and tools to complete these tasks; however this thesis will focus on the capabilities of Revit Structure to represent the structural reinforcement, which is why the next sections are limited to this field.

36 Structural analytical model Structural analytical model The analytical model of a structure is a conceptual mechanical representation of the physical entities which constitute a building. This simplified description is used as an dimensionally reduced engineering system to analyze and design the structure. Compared with the physical model, the analytical one is generated just with lines and points and the rich objects are not present anymore. Basically it describes only the geometry of the structure, but some abstract objects, e.g. loads and boundary conditions, are applied over it. Revit Structure associates the physical and the analytical model of the structure using an implicit dependency from the second one to the first one. In Revit the analytical model is generated in an automatic manner when one creates the model elements. It can be modified and improved manually in order to represent more accurately the physical system. [Autodesk(2007b)] Figure 2.12: Analytical and physical Model of a simple bridge formed by a concrete girder slab and its respective rectangular Piers. Revit represents the analytical model of the structure by means of structural members ; each structural element has the following components in the Revit analytical model: [Autodesk(2010b)] Instance parameters. Unique values which characterize the element, i.e. the specific applied properties.

37 Structural analytical model 22 Physical material properties. These are the values taken from the assigned material type. In Revit it is possible to generate new material types using a generic type or according to a predefined material schema, such as concrete, steel, wood, etc. The properties encompass material description, graphical preferences and mechanical definitions, e.g. Poison and elasticity modulus. Release conditions. This is the place to define the interaction in between the connected structural elements. The possible options to use are: Fixed, Pinned, Bending Moment, or User-defined, this last one allows choosing special support conditions fixing or releasing the axial and shear forces and the bending and torsion moments. Default position relative to the structural member itself. The analytical model can present an eccentricity with respect to the geometrical center of the element; because the physical model is just a guide to generate the analytical one and sometimes, in order to have a more feasible representation, it is necessary to change its position. A good example of a case when we need to modify the analytical model is shown in the Figure Figure 2.13: Top: Analytical model without any modification, note the discrepancy in the connection points of the beams. Bottom: Corrected analytical model. Location with respect to a projection plane. It refers to the relative position of the reference plane. In order to understand this clearly we can think about a rectangular beam, its analytical model goes from point A to point B, but the relative location of the beam concerning the analytical line can vary; thus from a point outside the beam, the analytical line can be either in the bottom, the center or the top of the beam. The application of loads and boundary conditions is also possible on Revit Structure. In the case of loads, there are three different geometric families: point, line and area load; the loads are applying usually on host elements, e.g. beams, slabs and walls, and their magnitude and position can be changed at any time. The boundary conditions can be applied like point, line and area as well; there are three default values: fixed, pinned and roller. However the user

38 2.3. SOFiSTiK 23 can define his own combination of boundary conditions fixing or releasing the translations and rotation in the x, y and z directions. Another relevant tool is the possibility to set load combinations, which increase the quantity of information available to exchange with the different users of the model; likewise, they are standard information needed for every structural analysis. One of the more interesting functions of Revit Structure is the capability of checking automatically the concordance between the analytical and the physical models as well as load transfer among different elements, i.e. finding the supporting elements of element. This last application could be very useful if the user is interested in searching for the interactions and relations of the model elements. The analytical model is one of the most valuable sources of information for external applications, especially for FEM software. The data contained in it can be shared using interoperability functionalities; furthermore the model can be complemented with information about the static system, e.g. loads, boundary conditions and load cases. In the case of this thesis a direct link between Revit Structure and SOFiSTiK is used, which exports not only the analytical structure but also information about the structural elements, e.g. geometric and material definitions. 2.3 SOFiSTiK General description SOFiSTiK is a structural analysis and design engineering software with a comprehensive capacity to solve common problems in the AEC industry. The main feature of SOFiSTiK is its capability to perform a FE analysis of structures; however it can be applied to carry out other significantly tasks such as CFD analysis, soil mechanics, geometric modeling and, in short words, structural design of buildings, bridges and tunnels. This thesis is grounded exactly in this last issue, i.e. A&D of buildings, implementing the different tools provided by SOFiSTiK in order to complete the calculation of the required structural reinforcement in concrete structures. The SOFiSTiK workflow can be described such as a data network, in which there is a central node i.e. the SOFiSTiK database (*.cdb) that controls the information flow and it is able to share information with several peripheral modules. These adjacent modules are executable programs that retrieve information of the central database and text input files as well. Thus they have specific functionalities to complete particular tasks in the A&D process. There are many programs and they can be combined in order to solve complex assignments. For instance, a program is in charge of the definition of materials and cross sections AQUA, other one is used to perform the geometric modeling SOFiMSHC, other has the capacity to carry out the static analysis of finite element structures ASE and so on [SOFiSTiK AG(2011b)]. For this thesis the program AQB is especially relevant, since this module is implemented in order to complete the design of the elements cross sections, i.e. determining the amount of required reinforcing steel. In this way, the different modules are executed subsequently in order to complete the entire

39 General description 24 A&D process. There are two different options to control the working sequence and provide the input parameters to the individual SOFiSTiK modules: A TEDDY text input file (*.dat). This is a text file written in the CADINPcommand language, which can be created in the TEDDY editor. The CADINP language is an open input data format developed by SOFiSTiK and based on the CADINT project standards [SOFiSTiK AG(2011b)]. The program TEDDY is a text editor developed specifically to work with the CADINP language, but it has also the capacity to control the SOFiSTiK workflow, i.e. it can execute the diverse SOFiSTiK modules and incorporating the arguments given in the text file. The SOFiSTiK-Structural-Desktop (SSD). This is a GUI that controls the A&D process by means of dialogue boxes. When this option is selected, the input data, i.e. the geometric model, static system, etc., has to be provided either by means of a TEDDY input file or through other application linked to SOFiSTiK, e.g. SOFiPLUS or Revit Structure. In fact, the SSD generates text files written in the CADINP language and it utilizes the TEDDY editor to execute them. Once the entire A&D process is complete, SOFiSTiK can be also used to generate the corresponding documentation for the project. The results of the calculations can be visualized and printed by means of the program URSULA. Likewise, the module GRAFiX allows performing a graphical post-processing of the system, i.e. a visual representation of the results of the FE analysis and structural design. Preprocessing TEDDY SOFiPLUS Revit Structure Rhinoceros Processing AQUA SOFIMSHC SOFiLOAD ASE MAXIMA Postprocessing AQB BEMESS URSULA WinGRAF ANIMATOR SOFiSTiK database (*.cdb ) Figure 2.14: SOFiSTiK structure. Summarizing, SOFiSTiK is a technological tool with many capabilities regarding the structural engineering issues. It offers a complete framework to handle with the A&D process of a structure as well as the possibility to generate high quality output products. There are many diverse ways to implement this software, but in the context of this thesis the Revit-SOFiSTiK workflow see Section 1.2 was selected. In the following the link between both programs,

40 SOFiSTiK Extensions for Revit Structure 25 i.e. the SOFiSTiK extensions for Revit Structure, are described in detail with the aim to offer an integral overview over the applied technology in this Masters thesis SOFiSTiK Extensions for Revit Structure In order minimize the redundant work done by different teams of engineers, an open and constant communication flow should be established between the software packages used by the participants of the project. The most relevant link for an SBIM program, such as Revit Structure, is the one which connects it with a structural and FE analysis software. There exists several ways to exchange information from Revit Structure to different structural analysis applications see Section 2.1.3, this thesis is focusing on the link between SOFiSTiK and Revit, which is realized by means of the SOFiSTiK Extensions for Revit Structure (SeRs). Figure 2.15: SOFiSTiK tools bar placed on the additional modules tab of Revit Structure. Using this package avoids to transcribe information from one system to another, saving time and reducing the inherent errors to this process. SeRs provides a high quality link and supports the most noteworthy model elements: [SOFiSTiK AG(2011a)] Slabs, walls, beams and columns All families containing an analytical model Point, line and area loading Load cases Support conditions Grids SeRs description Once the model is finished in Revit Structure, including loads, boundary conditions and load cases, the SeRs can be used to integrate Revit and SOFiSTiK. Using the command Export, placed on the SOFiSTiK tool bar, it is possible to transfer to SOFiSTiK either the entire model or only a part of if, in the case of very complex models this characteristic could be very useful, in the same way one can choose also whether exporting the loads or only the geometry of the model.

41 SeRs description 26 After choosing the basic system information, the SeRs GUI is shown by the program; here one can modify the exporting parameters and improve the quality of the model in SOFiSTiK. The mesh parameters selected in this phase influence directly in the final result of the exporting process; values like maximum element size, refinement factor and element type affect drastically the model generated in SOFiSTiK and selecting not adequate options can derive in errors during the FE analysis. Figure 2.16: SeRs exporting GUI. The final product of the SeRs are a SOFiSTiK database, i.e. a *.cdb file, and a set of TEDDY text files (*.dat) which can be used to create an equivalent model in SOFiSTiK. The *.cdb file contains only basic information about the project, e.g. project name, design code and language, i.e. an empty SOFiSTiK database with the same name as the Revit project. Generally when an exporting process is made, 4 *.dat files are created, the name of these files is assembled using the name of the Revit project (projectname) and an special extension added to recognize the function of the specific file. The *.dat files are the following: projectname rvt.dat. Unique values which characterize the element, i.e. the specific applied properties. projectname aqua.dat. This file is used to define the cross sections and materials present in the project. As it is written in the file name, the SOFiSTiK program AQUA is applied here. projectname msh.dat. In this file the geometry of the model is generated using the SOFiSTiK program SOFIMSHC. A very important detail is that besides the geometric definitions of the elements, its Revit ID is also exported. Thus one can establish easily a relation between an element in Revit and its corresponding child in the SOFiSTiK model. projectname load.dat. The SOFiSTiK program SOFILOAD is used in this file. Clearly one can find here the definition of the loads applied on the model.

42 Results using SeRs 27 Figure 2.17: Set of files created by SeRs and Revit project. When an error concerning the information gotten from Revit Structure occurs during the FE analysis in SOFiSTiK, it is always possible either choosing different exporting options or modifying the *.dat files and run them again. Therefore a high user interaction is advisable in order to produce high a quality model and analysis in SOFiSTiK Results using SeRs In order to test the capability of SeRs to exchange information between Revit Structure and SOFiSTiK, two simple models were created and successively exported to SOFiSTiK. Once the model was generated in SOFiSTiK, a simple static analysis was performed in order to evaluate the effectiveness of the new model. The next instance presents a summary of the obtained results. Punctual supported slab The model consists on a reinforced concrete structure composed by one rectangular slab supported by a set of columns; this case of study was taken from the examples of design with the Eurocode 2 from the German Association for Concrete and Construction Technology (DBV). The model was created directly in Revit Structure with the help of the predefined views and families since the geometry did not require any special treatment. In order to probe the performance of SeRs to handle with loads and load cases, two area loads were applied over the whole surface of the plate in the direction of the gravity; the first one simulating the self weight and the second one as a live load with a magnitude of 5KN. The columns were clamped using the boundary conditions tool of Revit and a load combination using both loads was applied as well. The basic load combination applied to the structure can be seen at the equation 2.1, the 2 load cases created in Revit, Dead Load (DL) and Live Load (LL), were combined acording to the factors. 1.1 DL LL (2.1) The exporting process did not imply any problem, after selecting the configuration options the model was created automatically in SOFiSTiK and the geometry reflected exactly the model in Revit. However, not everything was perfect, the materials had some problems and a fast edition was necessary. The load and load cases were mapped without any problem, the same as the boundary conditions.

43 Results using SeRs 28 Figure 2.18: Top view of the testing slab. [Fingerloos(2011)] During the static analysis an error occurred because some elements of the main plate were very skewed, i.e. the magnitude of the internal angles of some elements was below the low established by SOFiSTiK. Nevertheless, the solution consisted just in changing the maximum size of the elements, which suppressed the error since the internal angles were increased. The problem took place basically because of the free mesh method used automatically by the program i.e. SOFiSTiK when it generates the *.dat files. Even when the geometry is not complex this kind of problems can happen and exporting the geometry more than one time could be needed. The best advice is always putting attention on the *.dat files and modifie them according to the specific requirements of the model, what can be carried out manually using a simple text editor or TEDDY. With an elemental knowledge about SOFiSTiK this is possible and the improvements really worth the time invested on them. Frames and slab formed by non straight line segments The second applying test of SeRs was not so successful as the first one, in this case the structure is not much more complex than the one analyzed previously, but the geometry of

44 Results using SeRs 29 Figure 2.19: Structure analysed with SOFiSTiK. The load case is the one created on Revit for the self weight. the elements was defined using non straight lines but curved segments. In Revit Structure this is possible by means of defining an arc of a geometric figure, such as a circle or an ellipse, as well as using splines. The Figure 2.20 shows the model in Revit, the curved lines of the beams were created with splines and the round edge of the slab was modeled with a segment of an elliptical arc. The generation of the elements in Revit Structure did not bring any problem and the exporting procedure was successful according to SeRs. However the model generated in SOFiSTiK did not reflected adequately the original one sketched in Revit. Firstly the curved beams were changed to straight elements, the starting and ending points were correct but the connection between the points was made through a straight line and did not respect the shape described in Revit. In the respective TEDDY file, in the block corresponding to the implementation of the module SOFIMSHC, the beams were described such as Straights and circular arcs, i.e. SLNB entities. What is in principle correct, however the data needed to describe the shape of the arc segment was missing, i.e. radius, coordinates of the center and normal direction of the circle plane, among others. With respect to the plate used to create a roof in the front of the structure, the situation was even worse because the program SOFIMSHC could not be completed, therefore the slab was not created in the SOFiSTiK database. The program claimed that the normal direction should be defined, but the real problem was basically that the coordinates of the arc were omitted and written as (0.0, 0.0, 0.0) in both, the initial and final point. The element was defined in SOFIMSHC such as a structural area and its boundaries as SLNB entities, exactly as in the case of the beams, so then even whether the program had included the right coordinates of the curved line, the same errors obtained before would have occurred. About the loads, boundary conditions and the static analysis, the first ones were exported correctly and the calculations produced congruent results, however these outcomes were based on wrong assumptions since the geometry of the SOFiSTiK model represented a different

45 Results using SeRs 30 Figure 2.20: conditions. Structure exported using the SOFiSTiK extensions, including loads and boundary instance than the one created in Revit Structure. Therefore the exporting process of the static system failed too. Likewise the supports are interpreted such as boundary conditions and their geometry is omitted in the exporting phase. Notwithstanding when the elements are defined using circular arc segments, instead of elliptical ones or splines, the geometric model generated in SOFiSTiK corresponds to the one modeled in Revit Structure. The problem in this case is the orientation of the cross sections, which are mapped with a 90 rotation. Likewise the loads are exported exactly as in the case explained above, i.e. they are generated such as straight lines and do not follow the shape of the element, thereby the exporting process of the loads fail constantly and a manual input is necessary. The above mentioned can be considered as a huge disadvantage for SeRs because SOFiSTiK is a very powerful software which supports complex geometries, including NURBS definitions, and the SeRs package cannot reflect this kind of models correctly in the corresponding SOFiSTiK database. Moreover it is very common finding segment of arcs in the structures, thus the incapacity of the SOFiSTiK extensions to handle them reduces considerably the situations where they can be applied fully, leading to a local implementation just in particular cases.

46 Limitations and Restrictions of SeRs Limitations and Restrictions of SeRs Unfortunately the development of SeRs is still in progress and there are also some limitations on its utilization, in some cases the user has to extend the information exported by SeRs and in other ones a control procedure over the exported data is recommended. In the following some of these restrictions are mentioned: [SOFiSTiK AG(2011a)] The design code of the SOFiSTiK database (*.cdb) has to be set via the Commands menu function System dialog and cannot be changed. Materials are not mapped correctly. The Materials have to be defined either in the corresponding TEDDY file (*.dat) or in the SSD project. The geometry of the foundations is not modeled and they are represented as pinned supports. In the SOFiSTiK database (*.cdb) the eccentricity of beam cross sections is only supported as an offset from the start and/or end of a beam. Eccentricity modeled in Revit as a curve cannot be exported in its full shape. It is possible to find errors during the meshing, generally due to overlapping lines of the analytical model. Group information for the SOFiSTiK model is not assigned. Only elements defined by means of straight lines are exported correctly. 2.4 Reinforcement in Revit Structure Revit structure has the capacity to complement the models with structural reinforcing steel. This is one of the more remarkable features of Revit because almost every concrete structure includes reinforcing steel and using Revit to represent it introduces the reinforcement to the universe of SBIM, including all the benefits that this implies See Section The category in charge to organize all the issues about this field is named precisely Structural rebar and it groups three families which are used to define the reinforcement in a structure, these families are: Reinforcing bars (rebar). This family is used to define the standard steel rebars, Revit includes a default type s library with the most used diameters and geometric properties for shape modeling. The type of the element contains information such as hook length, bar diameter, rebar material, bending radius, among others; creating new rebar types is the way to customize the mechanical and geometrical properties from a particular rebar. Besides the type, each rebar element allows selecting the hook type and direction or whether to use a hook in the beginning or in the end of the rebar. In the same way than the rest of the elements in Revit, data about the constructions stage and visualization preferences can be added to the rebar.

47 2.4. Reinforcement in Revit Structure 32 Rebar Hooks. Revit includes only 2 types under this family: standard 90 and 180 hooks. The degrees represent the bending angle and other hook properties, as the hook length, are defined by the rebar type. Rebar shapes. The rebar shape defines the geometric development of the rebar, said differently it provides information about whether to bend the bar and where to do it. For instance, one longitudinal reinforcement bar and one stirrup bar can share the same type and hook characteristics but they differ in the shape, only the stirrup is bent. Revit includes a library of rebar shapes as well, but since the reinforced concrete is a very flexible material about its geometry and the form of the reinforcement, the generation of new rebar families is an essential task in the modeling process. Creating a family just consists in sketching the geometry in a 2D plane parametrically, i.e. define the shape of the rebar in a specific plane without any particular magnitude, but using variable parameters. However this is also a big restriction because usually the complexity of the structures demands extending the shape of the reinforcement to a third dimension. Figure 2.21: Set of beams with the same type but different rebar shapes. The whole reinforcement category is used to create model components, that is to say the elements under this category need to be referenced to a host element in order to be placed into the model. The rebar hooks and shapes are always linked to a rebar type, for example it is not possible assigning a rebar shape to a door since the shape contains instructions that can be applied only to a rebar. The rebar itself also has some restrictions about permitted host objects, the basic requirements are that the host element has to be an structural component and its material type must be concrete, e.g. a wood beam can have the same shape and structural use than a concrete one, but definitely adding rebar to it is not possible. The next families encompass the valid host elements: [Autodesk(2010b)] Structural Beams Structural Columns Structural Foundations

48 2.4. Reinforcement in Revit Structure 33 Structural Walls Structural Floors Foundation Slabs Wall Foundations Slab Edges The hosting of rebars, and its respective hooks and shapes, is not a disadvantage but a very helpful and powerful feature of Revit, because the rebars are automatically linked to the host element and any modification applied to this will be reflected into the rebar as well. In the same way, the selected hook types and shapes are assigned to the rebar type and, as it was said before, it is exactly the rebar type which defines some of the parameters of those two. [Weir et al.(2010)weir, Richardson, and Harrington] Figure 2.22: Rebar created on a set of beams and a colum. The parametric representation allows referencing some parameters of the rebars and hooks, e.g. bending radius and rebar length, to the host element. For instance a rebar assigned to a beam could be defined using some properties of the beam, e.g. the beam width or length, so the parameters of the rebar would be modified at the same time than one modifies the beam; said clearly, a change in the host element length would imply also a change in the length of the rebar. It is also important to note that the geometric position of the rebar is defined locally with respect to the host element, thus a change in the location of the element does not change the coordinates of the rebar but the transformation matrix which defines its relative position. In the following the different procedures to create reinforcement in a model are described together with the methods that can be applied to the rebars.

49 Placing reinforcing bars Placing reinforcing bars Placing 3D rebar in a model consists basically in drafting it as we would do it in a 2D representation, in Revit every element should belong to an specific reference plane See Section and the reinforcement is not the exception, thus when a plane has been selected the problem is reduced to select the location and properties of the rebar. The selected plane will define the driving direction of the rebar, therefore a wrong election of the plane would derive in errors in the final 3D rebar object See Figure Figure 2.23: In order to create correctly a set of longitudinal reinforcement for the shown beam, the green plane has to be selected as a reference for the rebar. There exist two methods to place rebars in a model: adding rebar parallel to the work plane and perpendicular to the work plane. One has to note that the methods depend only on the work plane but not on the host element and, on the other hand, the rebar is attached to this specific plane although a rotation and translation independent on the host element is possible, correcting in this way the reference plane. The two methods are easy to understand and self explainable, they cover the basic necessities of the standard design: longitudinal and transversal reinforcement; and for special cases a non-orthogonal plane with respect to the driving line of the host element should be selected. Revit provides also the option to map the rebar along the host element, said differently repeating a single rebar several times. Independently on the elected placing method, one can choose a rule to define the distribution of the rebar inside the element; the rule could

50 Area reinforcement 35 be either the minimum clear spacing or the maximum space in between the rebar or a fixed number of them; a combination of maximum space and number of bars is also possible. The first rule consists about placing the rebar at the minimum clear spacing set between each other. In the case of maximum spacing, the rebar would be extended till they cover the complete perpendicular length of the host element, in the same way as the rebar length is defined according to the size of this. When a fixed number of rebar is selected, Revit calculates automatically a constant spacing depending on the length of the host element and the number of bars. One should note the length of the rebar is equal to the length of the host element by default but this parameter can be changed to improve the quality of the representation. [Sullivan(2009)] For instance, one can sketch on a cross section of a beam a single bar to represent a stirrup, and then just say to the program that this element has to be duplicated several times from the point A to the point B with some constant spacing, the operation should be repeated until the whole beam is completed by the corresponding stirrups. These groups of cloned rebar behave as one unit and the properties of each single rebar are exactly the same than the ones of other bars in the group, thus one change in the rebar type would be applied to all of them; they are named by Revit rebar set. Figure 2.24: Rebar set on a column. The complete group was create based on two single bars. Furthermore of the two placing methods, there are another two reinforcing tools which facilitate creating rebar: area reinforcement and path reinforcement. In the following they are briefly described Area reinforcement This tool creates a collection of well organized rebar inside the selected element, in other words several layers of rebar in a host element; each layer is an uniform set of rebar with the same length, rebar type and relative position with respect to the reference plane. The spacing in between the rebar must be constant and it is possible choosing a fixed number of

51 Path reinforcement 36 bars instead of the spacing between them. In order to apply the area reinforcement tool, the host element must be a plate, a structural wall or a foundation slab, and the assigned material must be concrete. A maximum of four layers can be created in the host element, one in the top and one in the bottom for both major and minor direction. The type, spacing, hooks and relative position can vary each other and they behave as a single object, that is to say when one moves a bar, one is actually moving the whole bar system. The geometry of the reinforcing area is defined by means of a sketched boundary and several of them can be applied to a single element according to the requirements of the selected element. The major and minor direction is defined exactly during the area sketching process and they have to be parallel to one of the lines which define the boundary of the area. Figure 2.25: Area reinforcement in a section view. The area reinforcement tool is very useful because placing every single bar on a plate could consume much time and the final result would be hundreds of individual bars without any relation between other, besides they belong to the same host element; thus a change in the design of the plate would imply a modification for each rebar inside it, but using the grouped area reinforcement this operation would be reduced to change the respective parameters in the definition of the object. However a big disadvantage of the area reinforcement is that the rebars created with this tool are not visible on a 3D view, the visualization is only possible if a section view of the host element is created. [Weir et al.(2010)weir, Richardson, and Harrington] Path reinforcement The path reinforcement could be considered a subset of the area reinforcement, it is in fact an adaptive reinforced area which can be placed either in the top or in the bottom of the host element; this has to have the same characteristics than the ones allowed for the area reinforcement tool. Placing path reinforcement requires sketching either a line or a set of lines on a valid host element, the rebar is created along this line and parallel to it, the rebar is extended till it reaches a predefined length, measured perpendicularly with respect to the sketched line. As in the case of area reinforcement, either a maximum spacing or a fixed number of bars has to be assigned and Revit generates the rebar according to this data. Path reinforcement is helpful to complete the creation of rebar in edges or around openings in a slab or structural wall. The visualization is limited to the section views over the host element as well as in the area case.

52 Structural detailing Structural detailing Detailing is a transcendental part of the documentation process during the design phase of a building. When we talk about detailing, we refer to the action of creating a clear representation, in two or three dimensions, of all the specifications and particularities concerning a specific model. Revit Structure provides a wide range of tools to carry out this task. In fact the area and path reinforcement tools are detailing instances because they are not present in the three dimensional models but only in the 2D sectional views; they even can be considered only esthetic elements, since one creates them just to improve the quality about the final presentation of the results but not about the model itself. Looking at the topic of this thesis, there are some considerations and requirements that one should take into account talking about detailing in reinforced concrete in order to achieve successful results: [Legrand(2010)] General quality of the model and accuracy. Even in the simplest cases, the concrete structures are very flexible; the dimensions of the cross sections change constantly, the components of the structure must be joined or separated from other ones, the reinforcement must be extended to the neighbor elements and so on. Therefore an accurate model is essential in order to get a true representation of what we want to have in the real world. Quality of the involved Revit families. Both the host elements and the rebar must have the correct definition parameters, including material, dimensions, shape, etc. Revit can handle the modifications in the model efficiently but one should try to keep the corrections in the minimum possible. Views names and configuration. The configuration of views cannot be treated as a trivial task. They define the output product of the whole design process, thus they will be used to judge our work. Showing the correct categories, applying filters, specifying object styles and selecting understandable names save time, increase the productivity and improve the quality of the detailing. Rebar Libraries. Creating rebar, hook and shape types is a redundant and inefficient task, because rebar families are systems families and they have to be created in the main model file, i.e. they cannot be imported; however there is the possibility to standardize them using a Revit template. Annotation quality. The annotations are the mean to share precise information with the final users of the model; in consequence they are one of the most important factors to determine the quality of the detail in general. Standardize the annotations is very complicated, hence its requirements can change broadly from one project to other; in this manner the generation of the complementary labels annexed to the rebar demands a big amount of working time. Revit avoids redundant work since once the detail is finished, any change in the model is reflected in all the views and details. The detailing process include both the creation of the three dimensional reinforcement and the subsequent generation of constructive details, i.e. 2D views of the structural elements

53 Revit Extensions for Reinforcement 38 Figure 2.26: Detail of an isolated footing created in Revit Structure. describing minutely each one of their components. In the case of the second one, every section or elevation in Revit structure can be used as a working space to add annotations and customize it as a complete detail or a section of one; once the view is ready, including the visualization options, it can be assigned to a detail sheet, a 2D space to assemble the views, sections and elevations which will be part of the detail. The detail sheets can be standardized since they are loadable families See Section and can be imported into the project. Considering the creation of the 3D reinforcement one can use the methods explained in the Section in order to place rebar, area or path reinforcement according to the respective requirements of the elements into the model. Another option is utilizing the Revit Extensions which provides a set of functions to generate reinforcement on beams, columns slabs, walls and other special elements. In the following this complement is tested and shortly described. This thesis focuses on the development of a third option for the generation of the three dimensional reinforcement using the Revit.NET API. The Chapter 3 is focalized in the description of this issue Revit Extensions for Reinforcement The Revit extensions are a set of applications which increase the functionalities of Revit in some specific areas. Static simulation, modeling, interoperability and construction documentation are the fields covered by the extensions; focusing on the topic of concrete reinforcement, the Revit extensions offer some interesting programs which ease generating of rebar on a wide range of element, e.g. walls, isolated foundations, beams and columns, as well as several functions to create structural detailing and documentation. [Autodesk(2010a)] In general, the applications contained in the Revit extensions are very intuitive and user friendly. Definitely they are not an analysis and design tool, even whether they offer the possibility to make simple simulations of beams, frames, slabs and trusses. It is possible also generating reports with the results of these analyses, but the use of them is limited.

54 Revit extensions Description 39 However the Revit extensions increase significantly the capabilities of Revit by means of interoperability features especially with respect to the FEM program Autodesk Robot Structural Analysis. Using the respective application, one can connect both programs through a bi-directional link and use the results of the analysis and design in order to create the 3D reinforcement in Revit Structure. Otherwise Revit extensions could be very useful since placing rebar in each single element of the project could be a very time demanding task and the Revit extension can solve this problem in a shorter period Revit extensions Description Revit extensions work basically using standard templates to generate the reinforcement. Independently whether the host element is a column, beam, wall or any other supported object, the creation process of the rebar follows some predefined rules and any case outside of these rules cannot be handled by the extensions. According to the type of object in which we want to place the reinforcement, we have to select the specific function oriented to that kind of element, their name consist precisely with the name of the supported element, some of these function are: Beams Columns Walls and walls corners Slab corners and openings Footings The basic procedure to generate the rebar consists in the selection of some initial parameters and the type of reinforcement that we want to create and then the program calculates the corresponding geometric data necessary to place the rebar in the host element, trying to follow the selected rules. One should take into account that the spans and supports are detected automatically, thus even whether only a single element is selected for the generation of the reinforcement, the final result depends on the surrounded objects as well. The reinforcing types and patters cover the basic cases of concrete design and with a careful treatment and choosing the right parameters one can obtain very good results. For special cases one can create the rebar manually or modify the set of bars generated with the help of the extensions. In Figure 2.27 one can see the different options to add rebar to a beam, parameters to define the stirrups and its distribution and properties of bars have to be selected; customizing a beam further than the main longitudinal reinforcement is possible using additional top and bottom bars. Another interesting function is the capability of the Revit extensions to detect interferences between the rebar. It is very common that several bars touch each other along the element, therefore localizing the points of interferences can improve notably the model. This is just

55 Results using Revit Extensions 40 Figure 2.27: Revit extensions GUI used to set the parameters for generating rebar in a beam. a descriptive function and does not offer the possibility to make any change into the model, but just the fact of having the information is a big advantage. The Revit extensions include also the option to generate automatically reinforcement for either the whole structure or only a selected region. On one hand this option is just useful for visualization issues, since Revit generates the reinforcement in an overall way, without looking at the specific requirements of each element; but on the other hand, in the case of simple structures when the minimum amount of steel is assigned to the most of the elements into the project, this function can save much time and combined with the selection and definition of high quality reinforcement templates, the created bars could fit very well with the results of the structural design Results using Revit Extensions It is not easy to test all the functionalities of the Revit extension concerning to reinforcement using only few examples, since their main capability is not the generation of the reinforcement itself but the link that they establish in order to get the data to generate the rebar and its subsequent documentation and detailing. Therefore the next examples cover only the rebar creating process, which even with all its limitations could be very helpful in some specific cases. Basic beam system The first example consists in a simple structure formed by columns and several beams, a very basic test but also a very common system that we can see every day. The columns are supported by spread concrete footings, thus the whole structure was represented by means of those three elements. The set of beams is constituted as a beam system however the inclusion of the reinforcement was made treating them as individual elements.

56 Results using Revit Extensions 41 Figure 2.28: Structure selected to test the Revit extensions. It is important to mention that, considering the fact that a model full of hundreds of rebar would not allow appreciating the real quality of the results, just son elements were selected to the generation of the rebar. In order to create the reinforcement for this model, the Automatic Reinforcement Generation tool was used, since the selection of the parameters will not be focused, but the final product of the program. One can see on the application dialog the different elements selected for creating the rebar. The program organizes the elements according to the type and for each type it is possible to select a predefined reinforcement template; in the case of this trial, the program had some problems to recognize that all the elements in the beam system correspond to the same type, that is why the beam system is solved as separated elements in this test. The creation of the rebar in the beams could be considerated such as successful. They are the easiest elements, talking about reinforced concrete, and in this case the beams are not under any special condition, in the same way their geometry is defined just by a straight line; in other words the simplest elements in the simplest conditions. The Revit extensions are able to create, with good results, reinforcement for continuous beams as well; the program detects automatically the supports and organizes the rebar in order to avoid collisions between them. Unfortunately, the program produced always errors in the case of the slanted beams. The distribution of the stirrups did not correspond to the selected template, even when an uniform patter was assigned the transverse bars were split in several groups and some gaps appeared between them. The longitudinal rebar did not have many problems, but they always were

57 Results using Revit Extensions 42 extended beyond the limits of the beams. A simple modification on the length of those bars could solve the problems, but doing that in hundreds of beams is a tedious and redundant process that should be avoided. Figure 2.29: Reinforcement in a slanted beam. Note the error in the stirrups distrubution. The other object considered during this test was a column with its respective isolated footing. Vertical columns do not represent a big challenge for the Revit extensions, however when the columns are extended beyond one level the quality of the results decreases, since the Revit extensions generate the reinforcement using very few predefined patterns, thus the specific requirements of the columns when they are connected to beams of slabs in different levels cannot be satisfied. For instance, several tracks of stirrups cannot be added and the diameter of the bars is fixed along the column, therefore the application of this functionality has to be restricted basically to uniform sets of reinforcement on specific regions of the model, e.g. the detailing of some complex connections could be solved readily generating very good 2D and 3D representation, using the different visualization advantages of Revit. In regard to the isolated footing, this element is one of the simplest foundations but the representation of its reinforcement can be time demanding and tedious, hence it requires longitudinal and transverse rebar in more than one plane. Fortunately this kind of foundation is by definition disconnected from other elements, with the exception of its respective column, thus the influence of the structure complexity is reduced and the templates offered by the Revit extensions can be applied with fewer restrictions than in other cases. Likewise one can focus on generating the documentation which can be also an arduous job instead of placing the corresponding bars manually. Isolated wall corner The second case of study is a concrete wall supported by a continuous footing. The wall has an L shape, i.e. it is in fact the corner of a structure, and it is only a separated element, without connections with other structural members. The Revit extensions count with two functions for the case of walls: creating the reinforcement for the wall itself and for the joining areas with other walls, i.e. the corners. It is important

58 Results using Revit Extensions 43 to mention that this tools generate 3D rebar instead of area reinforcement, even if this could be understandable for the case of a wall; this characteristic is remarkable because the set of rebar generated by the program has properties that improve the visualization of the model if we want to generate a 3D output or to detail some specific regions, however a top view would not represent exactly the traditional output result that one needs generally in the AEC industry. The rebar generated by the application for the walls consists either in one or two layers of bars in both horizontal and vertical direction. The spacing and the bar diameter is uniform for each direction and there is also the possibility to add pins and dowels using some predefined types and patterns. In the same way, the reinforcement in the corner was generated, for this instance the application allows aggregating horizontal and longitudinal rebar, offering the chance to select different diameters for the inner and the outer branches of the wall. The results of the package can be considered as acceptable and one can always enrich them placing rebar manually or modifying the ones created by the package. Figure 2.30: Reinforcement in a wall and its footing. Note the interferences between the rebar placed in the corner. Detecting interferences among the rebar is possible using a function of the Revit extensions and this was evaluated for these trial. The application demonstrated to be effective but limited. On one hand this truly shows the contact points of the rebar, even offering the possibility to select the involved rebar elements in Revit; moreover the program split the interferences in two groups: internal interferences and interferences with reinforcement assigned to another elements, which in turn are divided according to the respective host elements. But

59 Limitations and Restrictions of the Revit Extensions 44 on the other hand, moving a single bar is not the best way to reduce the interferences into a model, maybe a change in the design could be taken as the best option; likewise the reports generated by the application are very poor and they do not enrich at all the quality of the project. The footing under the wall was also tested using its respective function. The results are quite similar to the ones that one can get for an isolated foundation, but in this case the footing is not connected to a column but a structural wall. Two layers of bars can be added along the host element, only in the main direction and the spacing between the reinforcing elements is defined using a fixed number of bars. A transversal reinforcement and dowels are also options in the parameters of this application, the stirrups are spread uniformly along the foundation and the diameter is constant for each set of model elements. One has to note that there is not any tool to create reinforcement on slabs, considering that a slab and a wall are basically plates it is logic thinking that the Revit extension are able to help with task but it is not true. However, there are two tools which can be helpful for adding rebar to these elements: slab openings and corners. As in the case of walls, a special set of rebar can be assigned to the corners, of course a corner in a slab is very different than a corner in a wall, but the package support both; again these elements are not area or path reinforcement so they are perfect for detailing or special and innovative output products. Figure 2.31: Reinforcement generated with the Revit extensions around an opening in a slab Limitations and Restrictions of the Revit Extensions Previously the general restrictions of the Revit extensions were mentioned, in short words, the reinforcement requirements vary constantly and only the standard cases are covered by the extensions; however there are some specific events where this package cannot be applied. The following points outline the main limitations for the employment of the Revit extensions. Only structural elements are supported. The non structural elements are not very

60 2.5. Revit.NET API 45 relevant in Revit structure, but they need reinforcement as well and the extensions cannot be used to generate it. The cross section of the beams must be rectangular; any other shape is not supported. However in the case of columns, round cross sections are also acceptable. Neither slanted columns nor slanted beams are supported. Likewise applying the complement to beams with a driving direction non orthogonal to the coordinate system always produces low quality results. Beam systems are not supported. This could be a very good example for standardization, but they have to be treated as single beams. The walls must have a rectangular shape and be uniform. Non rectangular walls can be processed by the extensions, but they produce wrong results. Any change in the profile of the walls is not recognized and the program generates the rebar for the entire wall. The geometry of the elements has to be defined by a straight line, curved segments, such as a beam created sketching a spline, are not allowed. The automatic definition of spans could introduce some errors in the final reinforcement. The length of the bars is defined using the information from the supporting elements and in some cases the assumptions of the applications lead to shorter or trimmed bars. The parametric definition of the reinforcement elements is not applied in its complete capacity, i.e. some of the parameters are calculated by the program and assign as constants, instead of creating references to the corresponding parameters of the host element. For instance, after generating the reinforcement on a wall, the modifications on the dimensions of the wall will not be reflected correctly, thus if the height of the element is changed, the rebar will not take the new size. This problem can be solved running the application again over all the involved elements, but this redundant task is inefficient and contradicts the essence of BIM. As a summary, one can say that the Revit extensions are a standard solution for standard problems; they can be used on simple or composite structures but when the complexity of the applied mechanical system or the geometry increase, their effectiveness and benefits are reduced widely. 2.5 Revit.NET API The Revit.NET API is a programming environment designed to write applications which can be executed on any Revit product, i.e. Revit Structure, MEP and Architecture. The API consist in two Dynamic Link Libraries (DLL) located in the Revit Program directory and each program based on the Revit API will reference them. These DLL s are: [Autodesk(2011a)] RevitAPI.dll. This DLL contains methods used to read, write and modify the different instances of the Revit application, such as documents, elements and parameters, directly from the project database.

61 Basic technology 46 RevitAPIUI.dll. This library encapsulates the interfaces related to manipulation and customization of the Revit user interface. The supported programming languages in the Revit API platform are any compatible with the Microsoft.NET Framework 3.5, such as Visual Basic.NET, C#, F# and C++. However the most common language used to develop applications via the.net API is C#, likewise the biggest amount of documentation and examples is referred to this programming language. By means of the Revit API one can access the model graphical data and parameters in order to create modify and delete model elements as well as manage the configuration settings and model views, basically all the functionalities of Revit are accessible through the API. On the other hand, one can use the programming interface to solve repetitive tasks, perform calculations and implement the results to modify the model, create project documentation and integrate Revit with external applications. A good example of an application written using the Revit.NET API is the SOFiSTiK Extensions for Revit Structure see Section 2.3.2, this gets all the relevant data to perform a structural analysis and link Revit Structure to SOFiSTiK. This thesis focuses on developing an application using the Revit API in order to illustrate by example the huge capability of Revit Structure with respect to the reinforcement in concrete structures Basic technology Writing an application based on the Revit.NET API implies creating a class library, i.e. a *.dll file. This task can be done using Microsoft Visual Studio as compiler, but using another one, such as Mono by Novell, is also possible. In the corresponding DLL the Revit API libraries, RevitAPI.dll and RevitAPIUI.dll, have to be added as a reference, thus the functions contained on them will be available for our program. It is very important to note that one should always set the Copy Local property of the reference to false when the project in created, this avoids the debugger getting confused about which copy of the DLL to use and reduce the required disk space. The library has to be referenced to Revit in order to be invoked by the user, this link in between the library and Revit is made through a *.addin manifest file. This file contains an xml code with data about the application, for instance the name and location of the DLL, the name of the namespace to be implemented, the output text to use in Revit and a unique addin ID. 1 <? xml version=" 1.0" encoding=" utf -8"?> 2 <RevitAddIns> 3 <AddIn Type=" Command "> 4 <Assembly>C: \... \ LibraryName. dll</ Assembly> 5 <ClientId>cc1d65d3 2fa1 4afb a51c b6c8eh2t38e7</ ClientId> 6 <FullClassName>Revit. Class. Command</ FullClassName> 7 <Text>OutputText</ Text> 8 <Description>Library Description.</ Description> 9 <VisibilityMode>AlwaysVisible</ VisibilityMode> 10 </ AddIn> 11 </ RevitAddIns> Code Region 2.1: Structure of a *.addin file.

62 Application structure 47 The manifest file has to be stored in a specific folder appointed by Revit to organize all the possible addins, the path of this folder can change from system to system but for Windows XP it looks as follow: 1 C : \ Documents and Settings\<user>\Application Data \ Autodesk \ Revit \ Addins \2011\ Code Region 2.2: Usual location of Addins in Windows XP. Once the addin file is stored in the respective folder, Revit will read it and will add it to the additional modules tab. The user would be able to use all the Revit functionalities as usualy plus the new ones written in the program, in the same way an interaction in real time with the user is possible as well. Debugging is allowed, but there is a problem when Visual Studio 2010 (VS2010) is used to write the program. VS2010 does not attach the Revit.exe process correctly because it uses the.net Framework 4.0 debugger, although it is a.net Framework 3.5 application as the case of the Revit API. The solution for this inconvenient is specifying the version of the Common Language Runtime (CLR) that has to be used by the compiler. In few words, the Revit configuration file, i.e. revit.exe.config, has to be edited adding the following code at the end. [Microsoft Corporation(2010)] 1 <startup> 2 <supportedruntime version=" v " /> 3 </ startup> Code Region 2.3: Code used to define the Framework version; this can change depending on the configuration of each system Application structure There are two different options to integrate an application based on the Revit API, writing either an external command or an external application. The interfaces required to create these two kinds of programs are contained in the library RevitAPIUI.dll, the specific methods used to produce them are described in the following. [Autodesk(2011a)] IExternalCommand An external command allows to call the main method from a DLL, in the Revit API this method is always called Execute(... ). They are located in the external tools tab in the Revit GUI and can be called manually or on a certain event by means of an external application. When a command is executed, an object of the type Command is created and successively destroyed when the Execute(... ) method returns the corresponding value to Revit. 1 public class Command : IExternalCommand 2 { 3 public Autodesk. Revit. UI. Result Execute ( 4 ExternalCommandData commanddata, ref string message, 5 Autodesk. Revit. DB. ElementSet elements ) 6 { }// Execute

63 IExternalApplication 48 9 }// Class Command Code Region 2.4: Implementation of an External Command. Two commands cannot be executed at the same time and they cannot share data, therefore the communications between them has to be performed using the Revit shared parameters, saving in this way data among several command executions. The Execute(... ) method requires the next arguments: CommandData. Contains a reference to the current application and the view to be used as a platform to launch the command. The data type of this object is Autodesk.Revit.UI.ExternalCommandData. Message. Error message of type string which is shown when the program fails on a dialog box. Elements. Set of elements selected on the Revit GUI which are referenced by the external command. The data type of this parameter is Autodesk.Revit.DB.ElementSet IExternalApplication An external application is a program which is executed immediately after Revit is started. The applications are running actively during the execution of Revit and they can be used to call external commands or other functions. The external applications have two abstract methods, which are called automatically when Revit starts and when Revit is closed: OnStartup(... ) OnShutdown(... ) 1 public class Application : IExternalApplication 2 { 3 // OnStartup method i s c a l l e d when Revit s t a r t s. 4 public Result OnStartup ( UIControlledApplication application ) 5 {... } 6 7 //OnShutdown method i s c a l l e d when Revit i s c l o s e d. 8 public Result OnStartup ( UIControlledApplication application ) 9 {... } }// Class A p p l i c a t i o n Code Region 2.5: Implementation of an External Application. However it is also possible to assign functionalities to certain events during the execution of Revit using the EventHandler method. For instance, the ribbon panels are created and customized using the External Application method, and their buttons are bound to an event to call some specific command or function on the execution.

64 Transactions Transactions Inside the main method of an external command, i.e. the Execute(... ) method, there is only one way to implement changes in the Revit database, that is through the Transaction class. This object is used to enable modifications on the Revit database and to close it after the application is finished. The class contains the next methods: [Autodesk(2011a)] Start( ). Points the beginning of the transactions and opens the Revit database to read/write processes. Commit( ). This method is used to end the transaction and launch the applied changes to the Revit document; the changes will not be reflected in the model till the transaction is committed. Rollback( ). It shares the ending function with the Commit( ) method but in this case the changes implemented by the application are discarded. GetStatus( ). This function returns the current status of the transaction, the possible return values are: uninitialized, started, rolledback, committed and pending. 1 Transaction transaction = new Transaction ( commanddata. Application. ActiveUIDocument. Document, " External Tool" ) ; 2 try 3 { transaction. Start ( ) ; } 4 catch ( Exception ex ) 5 {... } 6 finally 7 { transaction. Commit ( ) ; } Code Region 2.6: Transaction s structure. Exactly one transaction per document is allowed to be running at the same time; nevertheless the SubTransaction object can be used to produce some intermediate results during the execution of an application. An important characteristic of the sub-transactions is that they can be nested but they have to be closed before the parent sub-transaction or transaction is ended Database organization The Revit API interface is organized according to the hierarchy of the Revit project. The head of this hierarchy is the application object, which is created with the help of the classes Autodesk.Revit.UI.UIApplication and Autodesk.Revit.ApplicationServices.Application. This object represents the current Revit session and gives access to the project and its settings; in the same manner it provides functions to manage the application events, shared system parameters and project information. The Revit project, i.e. the database, is represented by the document object which belongs to the classes Autodesk.Revit.UI.UIDocument and Autodesk.Revit.DB.Document. It is used to create, delete and edit the content of the Revit project, including the geometric entities, families, types and the project settings, such as project information, parameters, phases,

65 Elements 50 style, units and structural settings. Thus the generation of new elements is carried out by means of this object through the corresponding creating method. [Autodesk(2011a)] Opening and producing new documents is possible as well, a Revit project or a family can be initialized using a template and added to the current application, and therefore more than one document can be opened and edited at the same time. Likewise the mange of the views is handled by means of this object, specifically using the class UIDocument Elements Every physical component present in the virtual model of a building, e.g. beams, columns and walls, is treated as an element by Revit Structure, these entities are specifically named model elements and besides them there are another 5 kinds of elements in the Revit database: Sketch, View, Group, Annotation and Information. Taking a look at the model elements, they are organized following a hierarchical structure see Section , in descending order the different levels look as follow: Category Family Symbol Instance Note that the last two levels have different names than the ones implemented in the user interface, thus a symbol corresponds to a type and an instance represents a model component or a host element. In the Revit environment there are two types of families, system and component families, through the API it is possible creating and loading new components of the second kind of families, but the system families are not available for editing and generation; likewise the properties of both family types are available for reading. There are three objects implemented in Revit to manage the families, types and elements: [Autodesk(2011a)] Family. This object is used to store families according strictly with its definition. For example a set of rectangular beams with common characteristics and parameters. FamilySymbol. The symbol is another name for type, thus this object represents specific types from a family, such as a rectangular beam with predefined dimensions and material. FamilyInstance. The family instance is an item of a specific type, they are used to represent model component, i.e. the elements. A particular beam type can have several exact copies in the model, differing only in their location; these copies are called in the Revit API FamilyInstances.

66 Parameters 51 In the Revit API the upper levels of the organizational hierarchy can be accessed by means of the elements, since they contain a reference to their respective type, family and category. In the same way the elements are accessible through the selected element set, included in the Application class, or using the get Element(... ) method from the Document class, and the specific element ID object. The element ID s are in general positive integers stored as a member of the ElementId class, however in some special cases they can turn into negative quantities, e.g. the value of the beam s vertical projection when it is customized. The ElementId should not be confused with the Globally Unique Identifier (GUID), which is represented by the object UniqueId and is used to exchange issues in between different Revit versions. The properties of the elements are public instances of the element object, hence they can be read very easily, however it is not possible to create new properties on an element since it implies changing the corresponding family. Editing the properties of an element can be done by changing the values of the corresponding members of the element class, however some of these members can be stored as read only and the modifications are not allowed; for these cases the internal built-in parameters have to be used Parameters The parameters are the values which define an element, its appearance and its behavior. In the Revit API the parameters can be accessed using the element property Parameters, this is a parameter set that collects all the properties assigned to an element. Besides they can be modified in order to improve and update the properties of an element applying the set(... ) method. Every default element parameter in Revit has an associate built-in parameter ID, i.e. an unique object of the class ElementId which is used to identify them. The parameter ID is another way to get the data contained in the parameter, this applying the get Parameter(... ) method of the element object. Nevertheless not all the parameters in Revit can be accessed using this method, such as the family parameters, in this case a loop iterating over the parameter set has to be implemented. [Autodesk(2011a)] The content of a specific parameter can take any valid Revit type, so the supported data types in Revit are: Integer. Signed 32-bit integer. Double. Standard 64-bit floating point number. ElementId. When the value of the parameter is, in fact, another object, an implicit reference is created using the element ID; for instance the parameter used to represent the material of a beam is stored as an ElementId, thus when the value is retrieved, Revit does not return the material object but the corresponding ID. None. Null value used internally to represent an invalid data type.

67 Filters 52 1 // Modify Length parameter through i t e r a t i o n over the parameter s e t 2 double len =5.0; 3 ParameterSet SetOfParameters = el_01. Parameters ; 4 foreach ( Parameter par in SetOfParameters ) 5 { 6 if ( par. Definition. Name. ToString ( )==" Length" ) 7 { 8 par. Set ( len ) ; 9 break ; 10 } 11 } // Modify Length parameter using the BuiltInParameter 14 Parameter param = el_01. get_parameter ( BuiltInParameter. INSTANCE_LENGTH_PARAM ) ; 15 param. Set ( len ) ; Code Region 2.7: Edit parameters by direct access (bottom) and parameter set (top) The element parameters are a good option to store information, however they cannot be used to share information between two external commands; this task can be completed with better result using the shared parameters. These are new customized parameters attached to the elements which are not stored in the Revit database but in an auxiliary *.txt file. Each parameter is defined by means of an unique identifier, thus they can be called by different commands and even different documents and applications Filters An interesting class that can be applied to organize the elements contained in a set is the FilteredElementCollector. This object includes methods to filter and classify the selected elements into a document; so three different types of filters can be applied to an element set: ElementQuickFilter, ElementSlowFilter and ElementLogicalFilter. [Autodesk(2011a)] The last filter type is defined as a combination of two or more filters by means of a logical operator; the main difference between the other two filters is the level of access to the information, the quick filter only offers data contained in the low-memory ElementRecord class. On the other hand, there are several predefined built-in filters that can be applied in order to improve and delimit the element set, some examples of this filters are: ElementClassFilter ElementCategoryFilter ElementStructuralTypeFilter FamilySymbolFilter ElementParameterFilter StructuralMaterialTypeFilter

68 Units in Revit Structure List<Element> element_x = new List<Element >() ; 3 foreach ( ElementId id_01 in selectedids ) 4 { 5 // S t r u c t u r a l type f i l t e r s f i r s t l y 6 LogicalOrFilter stfilter = new LogicalOrFilter ( new ElementStructuralTypeFilter ( StructuralType. Beam ), new ElementStructuralTypeFilter ( StructuralType. Column ) ) ; 7 // StructuralMaterialType should be Concrete 8 LogicalAndFilter hostfilter = new LogicalAndFilter ( stfilter, new StructuralMaterialTypeFilter ( StructuralMaterialType. Concrete ) ) ; 9 10 // Expected host o b j e c t 11 List<ElementId> l_01= new List<ElementId >() ; 12 l_01. Add ( id_01 ) ; 13 ICollection<ElementId> coll_01 = l_01 ; FilteredElementCollector collector = new FilteredElementCollector ( Document, coll_01 ) ; 16 FamilyInstance n_hostobject = collector. OfClass ( typeof ( FamilyInstance ) ). WherePasses ( hostfilter ). FirstElement ( ) as FamilyInstance ; if ( n_hostobject!= null ) 19 { element_x. Add ( m_commanddata. Application. ActiveUIDocument. Document. get_element ( id_01 ) ) ; } 20 }// Foreach Code Region 2.8: Filter applied in order to store in the List element x all the concrete beams and columns contained in the selectedids set. In some cases the required filter is exactly the opposite as one included in the set of built-in filters, in these situations some of the filters may be inverted, since most of them contain an overload constructor which incorporates in their input parameters a Boolean value to define whether using the standard version of the method or the inverted one. Not all the filters can be inverted, it occurs generally only in the case of slow filters; for instance, this situation happen for the FamilyInstanceFilter, RoomFilter and AreaFilter Units in Revit Structure The applied units system is an essential part of every application based on the Revit.NET API. Every calculation would be wrong whether the units are not congruent or they are not interpreted correctly. In Revit the displayed unit type is independent on the internal unit system therefore different predefined unit sets or a customized version of them can be selected and changed at any time during the execution of Revit. However the units used internally by Revit are always the same and when some data in retrieved using the API, it is given using the predefined Revit units. Revit includes a peculiar unit system consisting in seven independent base units see table 2.3, six of them based on a metric unit system and the other one, the length, on the imperial one, i.e. the unit for the length is the feet. Consequently the derived units for complex quantities, such as force or pressure, are unconventional types created by the combination of the base Revit units. For instance, the units

69 Structural Reinforcement 54 Base Unit Unit in Revit Unit System Length Feet (ft) Imperial Angle Radian Metric Mass Kilogram (kg) Metric Time Seconds (s) Metric Electric Current Ampere (A) Metric Temperature Kelvin (K) Metric Luminous Intensity Candela (cd) Metric Table 2.3: Base Units used by Revit. for the Young s modulus usually are P a or N, but in Revit the input/output internal unit m 2 is N, or more precisely kg. ft 2 ft s 2 It is very important putting special attention on the unit is transformation, especially whether the application is developed to perform some calculations, because the errors in the interpretation of the data are frequents. It is recommendable writing some special methods for the unit standardization and declaring some global constants for the unit is manipulation Structural Reinforcement Every structural element in Revit Structure can be created using the Revit API by means of the document class and the corresponding Create method. Thus the model can be enriched generating new beams, columns, walls and rebar. 2 // Create a new f a m i l y i n s t a n c e a c c o r d i n g to the given parameters 3 FamilyInstance newelement = Document. Create. NewFamilyInstance ( curveset, elementtype, toplevel, strtype ) ; Code Region 2.9: Generic method to create a new element. The new elements created on the document will appear in the Revit database and the functions of the application will have access to them but they will not be reflected in the Revit interface till the corresponding transaction is committed. In the following the issues relevant to the creation of new rebar in the model will be described Rebar elements The reinforcement is represented in the Revit API by means of the Rebar class, this object can be created using the Document.Create.NewRebar(... ) method which is an overloaded function with two variants: Creating rebar from an array of curves. This variant defines the geometry along the rebar using a collection of curves stored in a CurveArray; the hook type in the start and end point has to be specified, using a null value allows to remove the hook; likewise

70 Rebar elements 55 the rebar type must be defined, in this object information concerning the specific rebar, such as diameter and material, is stored. 1 Public Rebar PlaceRebars ( RebarBarType rebartype, RebarHookType starthook, RebarHookType endhook, RebarGeometry geominfo, RebarHookOrientation startorient, RebarHookOrientation endorient, bool stl, bool trans_op ) 2 { 3 Autodesk. Revit. DB. XYZ normal = geominfo. Normal ; // d i r e c t i o n o f rebar d i s t r i b u t i o n 4 CurveArray curves = geominfo. Curves ; // rebar curves 5 6 // Invoke the NewRebar ( ) method 7 Rebar createdrebar = m_createhandle. NewRebar ( Autodesk. Revit. DB. Structure. RebarStyle. Standard, rebartype, starthook, endhook, m_hostobject, normal, curves, startorient, endorient, false, true ) ; 8 9 return createdrebar ; 10 } Code Region 2.10: Implementation of NewRebar(... ) method to create rebar. An important condition concerning the CurveArray is that all the curves contained in the set must belong to the same plane, since this is a restriction for creation of reinforcement in Revit as well. The application developed for this thesis implements this specific method to create transverse and longitudinal rebar in the model. Creating a new Rebar based on a RebarShape. The main difference with respect to the previous method is that this one does not require hook and rebar types but a rebar shape which defines the properties of the rebar, including the geometry. When the rebar is created, the hooks are automatically removed from the rebar shape and whether a matching hook type is found in the Revit project, this will be assigned arbitrarily to the bar. In both methods the host element has to be defined, this must be one of the valid elements delineated by Revit Structure to incorporate rebar see Section 2.4. Through this object it is possible determining which reinforcing elements are assigned in order to calculate relative positions, extension and total quantities of rebar. With respect to the layout rule applied to the rebar, this can be specified using either the corresponding built-in parameter: REBAR ELEM LAYOUT RULE; or the set of methods offered by the Rebar class: SetLayoutAsSingle(... ) SetLayoutAsFixedNumber(... ) SetLayoutAsMaximumSpacing(... ) SetLayoutAsMinimumClearSpacing(... )

71 Rebar types 56 SetLayoutAsNumberWithSpacing(... ) In the following, a general description of the procedure to create the required objects for the generation of a rebar is delineated Rebar types The Revit API class RebarBarType is used to represent the different instances of the rebar family. Such as in the case of the rebar itself, there is a create method in the document class available to generate new rebar types, i.e. document.create.newrebarbartype( ). Note that this function does not include any argument, thus a RebarBarType is always created based on default parameters and then they have to be customized. Class members destined to edit the RebarBarType parameters are accessible and they enable modifications to the default values. In this way, new RebarBarType can be transformed from a generic type to one with the corresponding special requirements. Parameters such as name, bar diameter, bending diameter and hook length, are updated and bespoke. 1 // c r e a t e a new Rebar type 2 RebarBarType new_bar = Document. Create. NewRebarBarType ( ) ; 3 double fac_length = if ( new_bar!= null ) 5 { 6 // Set p r o p e r t i e s 7 new_bar. Name = " 14 BST 500 S" ; 8 new_bar. BarDiameter = * fac_length ; 9 new_bar. MaximumBendRadius = * fac_length ; 10 new_bar. StandardBendDiameter = * fac_length ; 11 new_bar. StirrupTieBendDiameter = * fac_length ; 12 new_bar. StandardHookBendDiameter = * fac_length ; 13 } Code Region 2.11: Creation of a new rebar type. Note the multiplication of the assigned values in order to have the correct units. However some of the members are marked as read-only values and they cannot be edited, e.g. Category, ID and ObjectType. At a glance, one can think that actually it is not necessary changing them; for instance the category of a beam should not be converted into other one, firstly because it is forbidden in Revit, and secondly because a beam never has to be turned into a wall or a slab. Nevertheless other parameters, such as the material of the rebar, are not fully accessible on the class member level. Thus in order to assign a specific material to the RebarBarType, one has to use the corresponding Built-in parameter, i.e. BuiltInParameter.MATERIAL ID PARAM, and the set(... ) method Hook types Document.Create.NewRebarHookType(... ) is the method implemented to create new Hook types. The input arguments are just the bending angle of rebar hook and the extension

72 Materials 57 multiplier of rebar hook. The return type of this function is RebarHookType object and, as in the case of the rebar types, it is initialized with some default values; for instance, the name of the hook type has to be assigned through editing the corresponding class member. Note that some of the properties related to the hooks are not defined in the RebarHookType object but in the RebarBarType to which it was attached. This is the case of the hook lengths (offset and nominal length), bending diameter, bending radius and others. So then in order to have access and customize these parameters inherent to the hook type, one should made use if the class members of the rebar type in a higher level, considering that in this level the properties of the RebarHookType will be only available by means of the respective built-in parameters Materials The materials in Revit are not represented by just one class, but by means of five different objects according to the material type and the specific parameters that define them: MaterialConcrete MaterialSteel MaterialWood MaterialGeneric MaterialOther The above mentioned classes are child of the base class Material which is used in the Revit API to manage the common properties of all the supported materials. This is a classical case of hierarchical inheritance, when many sub classes inherit from a single base class properties and members. The specific create method of each material type has to be used in order to create new materials in the Revit project, said differently the Material class does not include a generic function to create a particular material since the material types are based on different parameters and they have to be built using specific methods; for instance a new steel material can be created with the next method: 1 public bool AddSteel ( string mat_name, double young_modulus, double poisson, double ShearModulus, double therm_coeff, double unit_weight, double yield_stress, double tensile_strength, double reduction_factor =1. 54, double damping_ratio =0. 06) 2 { 3 // c r e a t e m a t e r i a l 4 MaterialSteel new_mat = Document. Settings. Materials. AddSteel ( mat_name ) ; 5 6 // Set parameters 7 new_mat. Behavior = MaterialBehaviourType. Isotropic ; 8 new_mat. YoungModulusX = young_modulus ; 9 new_mat. PoissonModulusX = poisson ; 10 new_mat. ShearModulusX = ShearModulus ;

73 Materials new_mat. ThermalExpansionCoefficientX = therm_coeff ; 12 new_mat. UnitWeight = unit_weight ; 13 new_mat. DampingRatio = damping_ratio ; 14 new_mat. MinimumYieldStress = yield_stress ; 15 new_mat. MinimumTensileStrength = tensile_strength ; 16 new_mat. ReductionFactor = reduction_factor ; //Add M a t e r i a l to l i s t 19 mat_steel_list. Add ( new_mat ) ; return Document. Settings. Materials. Contains ( mat_name ) ; 22 } Code Region 2.12: Method to create a new steel Material. The only required argument is the name of the material, in the same way that the previous cases, a set of default values is used to create a standard material and the class members of the specific material can be used to modify and customize the new material. There is a special case when a concrete material is generated, that is the characteristic concrete compression cannot be assigned directly by means of the members of the class MaterialConcrete, therefore, as it is explained in the Section , the corresponding builtin parameter, which is PHY MATERIAL PARAM CONCRETE COMPRESSION, has to be used. Assigning materials to a specific rebar type has to be made always through the built-in parameter MATERIAL ID PARAM see Section On the other hand, getting all the materials contained in the Revit project is possible applying a filter over the whole document and specifying the class of element that we want to retrieve. The code region 2.13 illustrates the procedure to obtain the materials and their successive classification according to the material type. 1 //Get a l l the M a t e r i a l s i n the f i l e 2 List<MaterialSteel> mat_steel_list = new List<MaterialSteel >() ; 3 List<MaterialConcrete>mat_concrete_list = new List<MaterialConcrete >() ; 4 5 FilteredElementCollector collector = new FilteredElementCollector ( document ) ; 6 collector. OfClass ( typeof ( Material ) ) ; 7 FilteredElementIterator materialitr = collector. GetElementIterator ( ) ; 8 materialitr. Reset ( ) ; 9 10 while ( materialitr. MoveNext ( ) ) 11 { 12 Material mat = materialitr. Current as Material ; 13 if ( mat is MaterialSteel ) 14 { 15 // s t o r e the M a t e r i a l S t e e l 16 mat_steel_list. Add ( mat as MaterialSteel ) ; 17 } 18 else if ( mat is MaterialConcrete ) 19 { 20 // s t o r e the MaterialConcrete 21 mat_concrete_list. Add ( mat as MaterialConcrete ) ; 22 }

74 2.6. 3D PDF documents }// while Code Region 2.13: Method implemented to find all the concrete and steel materials contained into the Revit project D PDF documents The Portable Document Format (PDF) is a formatting language designed for document exchange. The first version of PDF was released on 1993 and for this moment PDF was a proprietary format controlled by Adobe, it was till 2008 when the PDF specification became an open standard. The format was conceived with the goal of creating a communication standard to interchange high quality documents independently on the hardware, software or operative systems. [Adobe Systems Incorporated(2009)] A PDF file is in fact an already interpreted PostScript file; usually a Raster Image Processor (RIP) reads it and makes it into clearly defined objects, i.e. a raster image is also known as a bitmap. Said clearly, what we store in a PDF file is printing data from the information contained in the original file, the difference with the traditional paper printing is that the output is sent to the screen instead of to paper. [Evans(2011)] The PDF format has coexisted with other standard file formats with the same characteristics, such as EPS files, however unlike others, PDF documents describe how each page in the file has to look and also how it has to behave, for instance interactive checkboxes and text-edit fields can be added to a page and they can get some information from the user in order to complete a specific task. PDF files are enabled to contain text, fonts, images and multimedia elements, such as audio, video or 3D models, likewise they can include references either to other files or inside the same file, for instance a URL pointing to a web page. The format supports many remarkable features such as text search, random access of data, bookmarks, digital signs, annotations, interactive page elements, encryption, compression, Java scripts and metadata streams using XML among others. The high flexibility and the adaptability to the requirements of the users have made the PDF format the standard interchange format concerning written information in almost every field. It is very easy and practical creating PDF files and share them with all the people involved in a project, since they can be read by almost every computer with the appropriate software PDF internal structure PDF documents are organized as a hierarchical three see Figure 2.32 and the most of the objects contained on them are dictionaries, these can be purely structural elements or they can include more content and structures under their level. On the top level of the hierarchical structure is the Catalog Dictionary which encapsulates the content of the document and arranges the objects in a sequence of pages, i.e. it controls how the document would be displayed on the screen. Each page of the document is called in the PDF format page object, this can be defined as a dictionary that includes references

75 D models in PDF format 60 to the page s contents and other attributes. All the page objects in the document are related by means of a structure called page three. Each dictionary includes information about the relations between itself and the neighboring objects in the hierarchical structure. Pages Page tree Content stream Thumbnail image Annotations Outline hierarchy Outline entries Document Catalog Article threads Threads Named destinations Bead Interactive form Bead Figure 2.32: Structure of a PDF document. [Adobe Systems Incorporated(2006)] There are nine native types of objects in PDF: Boolean, real, integer, name, string, array, dictionary, stream and null. These types are called Indirect objects and they are used to define all the content of the PDF file; the information in the document is stored using these types and then secondary objects, such as page objects, establish references to them in order to organize the data. All the references between to indirect objects are stored in a cross reference table which is written in the end of the PDF file and allows having fast and efficient access to specific sections of the file without scanning large amounts of data. [Adobe Systems Incorporated(2006)] All the above mentioned constitute a brief overview about how actually PDF is working, the organization of the data and the supported features. However, granted that this thesis is not focused in the understanding and development of PDF technologies, the following sections are focalized only in the 3D representation of objects, since a high-level point of view D models in PDF format In 2005 PDF 1.6 specification was released and together with this new version of the format came the capability to directly insert three dimensional graphic objects into the documents, they were called 3D artwork. This new feature allowed to embed a virtual model of a physical entity, stored in Universal 3D (U3D) format see Section , on a document page. Unlike the 2D images, 3D elements are not referenced in the main content stream of a

76 D models in PDF format 61 page, but attached as an annotation. [Buchgraber(2010)] Nowadays the capabilities of the PDF format concerning 3D objects have increased and improved with respect to the first version. However, even now just 2 file formats are supported natively by PDF: U3D and the Product Representation Compact (PRC) format. It is easy to see then how important is developing translation tools from standard CAD storing formats to these two native PDF formats. Once the 3D instances are embedded in the document, they are presented by default as 2D rectangular areas and the user can choose whether activate them, thus this characteristic is used for printing issues. When the content of the 3D object is available, free rotation and translation are permitted using the corresponding tools, in the same way one can select some functions from the 3D tools panel and apply them to the model. Some of these functionalities are: Zoom 3D measure and comments Visibility options Illumination preferences Section views Figure 2.33: 3D representation of a Icosahedron. Besides the predefined scenes, one can create customized views which can be applied to the model. The views can modify the visibility options and the position of the virtual camera as well. Another notable feature of the views is that they allow to hide or to show the different layers of the 3D model; for instance, using as example a simple building, one can activate o deactivate the layer of the roof to have visual access to the inner zones. The views are shown

77 Universal 3D file format 62 in the section of model hierarchy form the PDF viewer and they are an important tool to enrich a 3D PDF file. Another interesting option to improve the quality of the 3D model is including a JavaScript that is used to manipulate 3D objects and their appearance programmatically. The JavaScript is attached to a 3D annotation and executed when this is activated. The JavaScript gives instructions to the model about its behavior and its visibility, but the possible functions applied to the objects depends hardly on the selected viewer and its version, since some of the functions are supported only by the scripting language but the host program cannot truly apply them Universal 3D file format U3D is a binary file format for 3D computer graphics data which was standardized by the European Computer Manufacturers Association (ECMA) in 2005 over the reference ECMA The original concept was proposed by a special consortium called 3D Industry Forum (3DIF) that agglomerated several firms such as Intel Corporation, Boeing, Hewlett-Packard, Fraunhofer Institute, Adobe Systems, Bentley Systems, SolidWorks and Right Hemisphere among others. [Buchgraber(2010)] The Universal 3D project is a attempt to create a reliable open file format to exchange 3D data independently on the used application in a standard way, thus the users of these files could share information and allow the visualization of models to third parts interested on the project. U3D offers the possibility to create intelligent documents; some remarkable characteristics of U3D are named in the following. Boundary representation of objects. High compression through binary encoding. Fully referenced architecture. Continuous level of detail. Support for materials and Shading. Textures included as PNG or JPEG files. After the 4th edition (2007), support for free-form curves and surfaces. Support for metadata as attributes. Animation support. The visualization in the U3D files is created by means of scenes in which different resources can be assigned to the elements in the 3D object; there exists 3 kinds of resources: node resources, shading resources and motion resources. The node resources contain the information necessary to render the 3D models, i.e. light, views and the geometry itself; the shading resources describe the visual appearance of the geometry when it is rendered, i.e. texture, material, etc.; and the last kind of resources contains animation data. [ECMA International(2007)]

78 Universal 3D Sample Software 63 U3D files are the best way to include 3D contents in a PDF document, since the U3D format is natively supported by PDF. The following Sections treat the methods to create a U3D file and embed it into a PDF document Universal 3D Sample Software In order to create U3D files, the 3D Industry Forum released an open source set of C++ libraries to write, read, extend, render and interact with U3D-formatted data. Even whether the libraries are limited in some aspects, they can be consider as a very good starting point to develop a more complex program and in many cases they are able to create the required 3D models. One can always write his own code based on the ECMA standards, but starting from the beginning could take a lot of time and it does not guaranty producing a more efficient program. In any case the libraries can be taken as a guide and a good example about how to proceed during the development of the application. <FILE_HEADER> <SCENE_DATA> <NODES> <NODE_RESOURCES> <MOTION_RESOURCES> <FILE_REFERENCE> <SHADER_RESOURCES> <MODIFIERS> Figure 2.34: Structure of a IDTF file. All the programs contained in the Universal 3D Sample Software are based on the third edition of the U3D, therefore they do not offer support for free-form curves and surfaces. Likewise precompiled applications are available to export, import, convert and visualize the U3D files; these applications could be very useful whether we are interested in working with a small amount of files or when our code is written in a different language to C++. Creating a U3D file can be done using a simpler format: the Intermediate Data Text File (IDTF). The method consists about writing the 3D model in the IDTF format and then use the converting program included in the 3DIF libraries to translate it into the U3D format. The IDTF is a human-readable format which shares several characteristics with respect to U3D, for instance they both work using references to some predefined resource tables that are used to create, modify and render the 3D objects. An IDTF file is an ASCII document which can be read with every available editor and contains text blocks which define different scene objects.

79 The movie15 L A TEX package 64 1 The organization of every IDTF file is made by means of the scene, since it defines what information would be presented; besides a scene one can find several nodes, but in IDTF a node is not only a point but a group which encapsulates several geometric entities. There are three different available geometric objects in IDTF: point set, line set and mesh; they are placed inside the model resources group as well as in a U3D file; in the same way, metadata can be added to the nodes, to the other resources in the file or to a specific scene or modifier. [Intel Corporation(2005)] Looking at the metadata text block in a IDTF file, this is written following a sequence of Key/Value pairs as is shown in the code region The values could take any type allowed in the U3D format and any key with string type can be assigned to them; however the contents of the metadata block have to fit with the pseudo-xml structure shown in the code region 2.14 as well. In this way the metadata will be shown in the final PDF file, more precisely in the properties section of the model hierarchy tab. [Adobe Systems Incorporated(2007)] 2 META_DATA { 3 META_DATA_COUNT 1 4 META_DATA 0 { 5 META_DATA_ATTRIBUTE " STRING" 6 META_DATA_KEY " RHAdobeMeta " 7 META_DATA_VALUE 8 " < namespace name =\" \" > 9 <item name =\" Structural type \" value =\" Reinforcement \"/ > 10 <item name =\" Rebar Name \" value =\"6 BSt 420 _Str \"/ > 11 </ namespace >" 12 } 13 } Code Region 2.14: Metadata text block in a IDTF file. Once the IDTF file is written, converting it into a U3D format is a trivial task using the respective 3DIF library. In this point the U3D object can be added directly to a PDF file without any other translation or special treatment, however there is a mandatory requisite: a professional version of Adobe Acrobat PDF or any other PDF editing software. Nevertheless there is another option, using L A TEX to create a PDF file and incorporating here the 3D object as a movie, in the following Section this procedure would be described The movie15 L A TEX package There exists some commercial tools to insert multimedia content to PDF files, e.g. the Tetra 4D Plug-in for Acrobat X Pro, Prostep PDF and PDF3D of Visual Technology Services, on the other hand there is a free and open-source tool for embedding 3D models to PDF documents, that is the Movie15 L A TEX package which can be used for inclusion of movies, sounds and, of course, 3D objects. [Buchgraber(2010)] Movie15 supports the PDF 1.6 specification, which was the first one that allowed incorporating 3D content in the document. The package provides an interface to work with both L A TEX and pdfl A TEX and produces a standard PDF file, i.e. a hardware and operative system independent file. The only requirement to open it is to have a PDF reader which supports the respective PDF implementation, for instance Adobe Acrobat Reader 7 or superior.

80 The movie15 L A TEX package 65 This package counts with several functions to implement the most of the capabilities of PDF referring to 3D entities. The following features are supported by Movie15: [Grahn(2009)] Besides the default view, a list of predefined views can be added from an external file with the extension *.vws. In this auxiliary file some parameters can be defined in order to apply them when the 3D contend is activated. As it was explained before see Section the views allow changing visual characteristics about the model such as illumination properties, deactivating a specific layer, position of the camera and background color. Only U3D and PRC formats are supported as origin format for the 3D objects. The metadata contained in the U3D file is mapped correctly on the PDF document, however the addition of data external to the one contained in the U3D file could be complex and the results are uncertain. JavaScript is supported but attached to 3D comments, thus an interaction with the model is possible. Hyperlinks are available by means of the \movieref command. Embedding a 3D model in the PDF document using Movie15 is not more complicated than including a picture. The code region 2.15 shows the code used to complete the task, in short words one only has to define the selected U3D file, then the dimensions of the 2D rectangular region that contains the 3D object and the predefined views, which where determined in this case by means of an auxiliary file. 1 \ usepackage [ 3 D ] { movie 15} 2 \ begin { document } 3 \ includemovie [ 4 poster, 5 toolbar, 6 label=3d Model, 7 3 Dviews2=Predefined views. vws 8 ] { cm }{17 cm }{ Model. u3d} 9 \end{ document } Code Region 2.15: L A TEX code used to embed a 3D object. However the generation of views is not an insignificant task because we cannot forget that the goal of creating a 3D PDF file is purely visual, thus improving the rendering and visualization of our model will be reflected directly in the quality of the whole file. A *.vws file is a text document containing one or more views to apply to a model, the first view in the file will be taken as the default view. The structure of a view can be seen in the code region 2.16, likewise the parameters defined in each view block are defined in the following. [Grahn(2009)] COO. Set of 3 real numbers which defines the positional vector of the center of orbit. The allowed range for the coordinates is (10 18, ). C2C. Direction vector with origin in the center of orbit to define the center of orbit and pointing to the virtual camera. It has the same permitted range than the COO.

81 D PDF from Revit Models 66 ROO. A positive value to specify the radius of orbit of the virtual camera. AAC. This parameter defines the aperture angle of the camera, measured in degrees; the given value has to be a real number between 0 and 180. If there this entry is not given a default value of 30 is given. BGCOLOR. Background color in RGB format with the range [1, 0]. LIGHTS. Lighting scheme, the possible values are: None, White, Day, Night, Hard, Primary, Blue, Red, Cube, CAD, HeadLamp. RENDERMODE. Set the default render mode, the possible values are: Solid, Solid- Wireframe, Transparent, TransparentWireframe, BoundingBox, TransparentBounding- Box, TransparentBoundingBoxOutline, Wireframe, ShadedWireframe, HiddenWireframe, Vertices, ShadedVertices, SolidOutline, Illustration, ShadedIllustration. 1 VIEW={Isometric } 2 COO = C2C= ROO = AAC = BGCOLOR = LIGHTS=Headlamp 8 RENDERMODE=Transparent 9 END Code Region 2.16: L A TEX Structure of a predefined view for a 3D PDF file D PDF from Revit Models Sharing information is one of the fundamental concepts of BIM and in consequence it is an essential issue in Revit Structure as well; the simplest, and maybe the best, way to exchange data is just exchange the complete Revit database, i.e. the *.rvt file. However according to the circumstances of each different situation, sharing the whole project is not so convenient because of diverse reasons: the information contained in the model has a big value and we should be careful with its management, not all the data contained the project is useful for the receiver, the size of the file could be huge, the receiver of the file could not have a full version of Revit Structure nor the knowledge and experience about how to use it, among others. In the case that we want to share the 3D model contained in Revit Structure, mostly with visualization purposes, creating a 3D PDF file is a very good option, since reading this kind of files is almost available for everybody with a computer or similar electronic devices. Revit Structure offers the possibility to create 3D PDF s through the IFC classes, the concept is very simple: since Revit is able to export the model in IFC format, an interfacing program with the capacity to read/write these specific formats (IFC,PDF) can generate a PDF document scanning this file. Thus the IFC files have to be translated to the U3D or PRC format in order to be embedded into the PDF document, this task can be carried out using some commercial software such as the professional version of Adobe Acrobat or the Tetra 4D Plug-in for Acrobat X Pro; with the file already in a supported native PDF format one should only include it as in the case of an image.

82 D PDF from Revit Models 67 However the Revit models are not reflected always in the PDF documents as we could expect, for instance when the columns are extended beyond one level they are mapped in the PDF just in the level that they were created, likewise another problems can occur. With respect to the case of 3D reinforcement, i.e. rebar, area and path reinforcement, the situation is worse because they are not supported at all for the previous mentioned applications and, even whether they are present in the IFC file, they are ignored in the converting process to the U3D format. This is a big limitation because a transcendental part of the reinforced concrete structures is simply omitted. In order to solve this issue and offer an option to interchange reinforcing data with others, the Revit.NET API was used to write a small application to create 3D PDF files based on the rebar and the corresponding host elements. The results can be seen in the Section

83 68 CHAPTER3 3DReinforcement: a Revit API implementation This Chapter describes in detail the application created during the development of this thesis, i.e. the 3DR program. The first part of the Chapter covers a basic description of the project outreach without putting much attention in the specific methods and programming structure implemented on the program. The next blocks are focused in the specific technologies that were developed in order to solve some crucial tasks to reach the objective of the project. Finally, the last Section delimits the cases where the application can be executed without any complication. In this way a general overview about the structure, function and scope of the program is completed. 3.1 The application 3DR The program 3DReinforcement (3DR) is an application written in c# and developed in the Revit.NET API environment, which has the capacity to generate reinforcing bars in a set of host elements with some specific characteristics. The application uses the information contained in a SOFiSTiK database in order to assign the properties of the rebar. The data source, i.e. the SOFiSTiK database, has to contain the results of a structural design carried out in SOFiSTiK and also particular information about the correspondence between the elements in both software packages. The aim of the program is extending the interoperability conditions that already exists between Revit Structure and SOFiSTiK by means of the Revit.NET API, i.e. creating a direct link see Section from SOFiSTiK to Revit, which can handle with the reinforcement generation in simple elements. Currently the communication just can be established in the opposite direction with some limitations see Section and the connection in the other way is a key part to reach a full interoperability between both programs and to enable a free exchange of information as is required in the BIM concept. As it is illustrated in the Figure 3.1 the program 3DR is integrated in the Revit-SOFiSTiK workflow. Likewise, it can be considered such as a complement for the SOFiSTiK extensions for Revit Structure which obviously is focused in the field of structural reinforcement; so the application cannot work outside of the Revit-SOFiSTiK environment and it was developed as an unidirectional communication channel. It is worth to remark that BIM is a process, i.e. a continuous series of actions, changes, or functions bringing about a result, therefore the

84 3.1. The application 3DR 69 BIM concept states how to proceed in order to create a virtual model of a building which is valid during its complete life cycle; thus the BIM loop is broken when the virtual data cannot flow freely between the different software packages required to complete the cycle. Revit Structure Model elements Loads Sofistik Extensions SOFiSTiK Material definition Static analysis Load combinations Boundary conditions 3DReinforcement API {... } Dynamic analysis Structural design 3DReinforcement API SOFiSTiK DB info Revit Materials Rebar and hook types Rebar elements 3D PDF Documentation Figure 3.1: Process of the 3DR application in the contex of the Revit-SOFiSTiK workflow. Besides the 3D rebar elements produced in Revit Structure, the application developed for this thesis, i.e. 3DR, offers the possibility to create a 3D representation of the reinforcement model and its corresponding host elements in PDF format as an alternative output product. This functionality was included because the potential of a 3D representation of reinforcement has not been totally explored till now, in the context of the Revit-SOFiSTiK workflow, and its usability in the future can mean several interesting benefits. In the following the main features and working process of the 3DR application are depicted point by point in order to present an overview of its capabilities and applicability.

85 Basic technologies Basic technologies The programming language C# was selected to develop the software 3DR, this because of the big amount of documentation and samples available for developers concerning the Revit API, and because of the notable features of the language compared with other alternatives, such as VB.NET. Likewise the code was written and compiled in Visual Studio 2010 (VS2010), with the detail that the.net Framework 4.0 was not used but the version 3.5 because of the specifications of the Revit API. The final product of the compilation was a DLL with the name: 3DReinforcement.dll; this file is fully dependent on Revit Structure and it cannot be executed outside of the Revit environment. The application is written such as an external command see Section and can be called from the external commands menu from the additional modules tab in Revit Structure. Both DLL s of the Revit API are applied, the specific API classes that are used for the program are: Autodesk.Revit.UI.IExternalCommand Autodesk.Revit.Creation.Document Autodesk.Revit.DB.Structure.Rebar Autodesk.Revit.DB.Structure.StructuralType The Document.NewRebar(... ) method is implemented by the application in order to generate the rebar elements. The variant for the overloaded function that was chosen is the one that incorporates as arguments the rebar type, hooks and a curve array to define the shape of the corresponding bar. The dynamic library cdb w25.dll is implemented by the program, this is a SOFiSTiK DLL which allows retrieving data from the SOFiSTiK database. Thus, in the case of the 3DR application, the information about the rebar, which was generated after the structural analysis and design process, is scanned in order to set the properties of the 3D reinforcement that will be generated in a next phase Workflow The 3DReinfocement application is designed to work in some special conditions, i.e. it cannot be executed indifferently in every concrete element present in the Revit model. The most important condition to define a valid element is that it has to be included in the SOFiSTiK database as well, i.e. the elements in Revit structure need a corresponding element or set of elements in the SOFiSTiK model, this relation between both databases is reached by means of the Element ID, which is mapped by the SOFiSTiK extensions into the SOFiSTiK database during the exporting process. So then, in order to complete successfully the representation of 3D reinforcement in one element or an entire model using 3DR, the next steps have to be completed successively: 1. Create a new project in Revit Structure.

86 Workflow Generate the model according to the particular requirements of the project. 3. Include loads, support conditions and load combinations in Revit Structure. 4. Export the entire model, or a fraction of it, to SOFiSTiK using the SOFiSTiK extensions for Revit Structure. 5. Define correctly the materials in SOFiSTiK. 6. Complete the corresponding structural analysis in the equivalent model. 7. Calculate the required reinforcement and define its specifications. 8. Back in Revit Structure, select the host elements in which the Reinforcement will be created and run the application. This process can be done in more than one phase and if some element without a reference in the SOFiSTiK database is selected, then the program will just ignore it. 9. Optionally, create a 3D model in PDF format of the previously produced reinforcement and the corresponding host elements, this using a L A TEX interface as a complementary tool. 10. After generating the reinforcing bars in Revit Structure, a process of manual refinement can be carried out in order to improve the quality of the reinforcement. Revit Model Apply Static system SeRs SOFiSTiK Model 3D PDF Latex 3D Rebar 3DR Analysis & Design Figure 3.2: The process of the 3DR application. The dashed lines denote the optional sections. The process has a strict order and the steps cannot be skipped in order to obtain consistent results. For instance, the reinforcement cannot be generated whether there is not any SOFiSTiK database or whether the existing database does not contain information about the properties of the respective rebar. However once a first loop is accomplished, some corrections can be done starting on an intermediate point; this is the case of errors in the calculation of the amount of required steel made on SOFiSTiK, if the FE analysis or the structural design had some inaccuracies, the process can be taken again up at this point in order to produce a new SOFiSTiK database and used this information to generate a new set of bars in the elements. Likewise it is important to note that the names of the Revit project and the SOFiSTiK database have to match each other, said in other words they must have the same name. This does not imply any new task for the user because when the model is exported from Revit, then the SOFiSTiK extensions create a database with the same name as the Revit project

87 DR Outcomes 72 by default, thus if the SOFiSTiK database is replaced by other one, the name has to be consistent. However the denominations of both databases can be changed as long as they remain analogous DR Outcomes Revit Structure offers three different possibilities for the 3D representations of reinforcement: rebar elements, area reinforcement and path reinforcement; an overview about each of them is presented in the Section All the output products generated by the application 3DR are model components of the category Structural reinforcement, i.e. rebar elements, rebar types and hook types. Besides equivalent materials to the ones defined in the SOFiSTiK database are created, this with the limitation of the case of study, steel and concrete. In the following the particular outcomes generated by 3DR are described carefully in order to present a clear view about its applicability A 3D reinforcement model in Revit Structure The main result retrieved after the execution of 3DR is a set of rebar elements which represent both the longitudinal and the transversal reinforcement. The dimensions and quantities of the rebar are defined using the information scanned form the SOFiSTiK database by means of the explicit relation between the elements in Revit and the equivalent SOFiSTiK elements established through the element ID. The object rebar has many remarkable characteristics which set it in a privilege place over the other two available options. Firstly it is visible in 3D views and not only in section views as the other ones, this property is very relevant for detailing issues and in order to check whether the created set of rebar effectively fit with the specifications of the project. Furthermore, local manual modifications in order to improve the results are easier and more practical when the influence region of a specific rebar set does not reach several critical points, such as connections between elements. Each rebar created in Revit Structure is related to a specific rebar type, hook types and materials. These are generated following the schema taken from the SOFiSTiK model, usually they are stored in the Revit database and shared between all the rebar in the Revit model with the same properties. Thus in order to include rebar with a specific diameter in an element, the program generates a new rebar type which includes materials and hook types created in a previous step; one should note that even whether only one property of the rebar differs for other one then a new rebar type has to be produced. The names of the new types and materials are defined automatically by 3DR and if an instance is already stored in the database with the same name, the program does not delete it but update the properties of the entity in order to preserve the possible references to this element. In this way, several loops of reinforcement creation can be done without any risk to produce inconsistencies among the elements and the databases. Once the rebar sets are placed in the selected element, the application forms a Revit group including all of them, in this manner the management of the 3D bars can be carried out in an organized way avoiding the problem of having thousands of independent bars in a model

88 A 3D reinforcement model in Revit Structure 73 without any clear relation between the rebar that belong to the same element. It is important to clarify that one group is created per each valid element included in the selected set and they can be found in the model groups section from the project browser in Revit Structure; the particular names of the groups are integrated using the element ID and the keyword Rebar as is shown in the Figure 3.3 with this format: Rebar ElmentID. Figure 3.3: Set of reinforcement bars created by 3DR in a beam. Note they are grouped under the name: Rebar The number of reinforcing layers is determined by simple analogy with the quantity of layers generated by SOFiSTiK, likewise the relative location and length is calculated according to the scanned data; thus the definitions contained in the SOFiSTiK database are mapped, in the most accurate possible way, to the Revit project. With respect to the transverse reinforcement, a simple rectangular shape around the perimeter of the corresponding structural element is the only possibility because this shape is the most used and common and the development of the program is not focused in specific cases but in simple ones in order to prove the viability of the generation of rebar by means of the Revit API. The recover employed on the host element is also calculated using data read from the SOFiSTiK database, in fact not any recover is assigned to the elements in Revit, but the rebar is placed according to the location of the reinforcing layers in SOFiSTiK, respecting in this way the distance between the rebar and the borders of the host element. Likewise, the rebar created in the selected element is divided in sections along the same one, in other words it is possible generating several groups of rebar in between of the element. The number of groups is defined according to the variations of the required steel along the elements; for instance, if the quantity of steel which has to be incorporated to the object is constant, or with small discrepancies, then the program will generate just one set of rebar. In other respects, a set of files is written by the program in order to provide the required tools to create a PDF document from the 3D reinforcement model. This collection of files is

89 The reinforcement model in PDF format 74 integrated by the next components: one IDTF file, in which the reinforcement model is described; a U3D model generated with base on the IDTF description; a *.vws file including the predefined views; and a L A TEX script which can be executed in order to generate a PDF document, the only requirement to do it is the previous installation of a L A TEX implementation, such as MiKTEX. Finally, the user can apply all the tools available in Revit in order to create new visualization outcomes, such as section views and documentation sheets. Revit Structure incorporates several functions to perform the complete structural detailing process and combining these with the data about the calculations generated in SOFiSTiK, the whole documentation respecting the reinforcement model can be integrated. Optionally the 3D PDF file produced by 3DR can complement this set of output products, in the following the description of this option is depicted and extended The reinforcement model in PDF format A secondary product of the 3DR process is a group of four files which allows to handle with the generation of a 3D model of the reinforcement and the corresponding host elements in PDF format. The name of the files is assembled using the name of the project and a default complementary extension, in this way the file set is integrated as follow: projectname.idtf projectname.u3d projectname views.vws projectname.tex The *.u3d file is produced automatically by the 3DR application with the help of the specific 3DIF library see Section implemented to create U3D files based on the definition of a model written in the IDTF format. Thus the final U3D file contains the 3D representation of the host elements and the reinforcement model, but besides of the graphic data, the file also contains basic information about the rebar type attached as metadata to the specific elements. The metadata is annexed to the 3D model in order to present particular information of the reinforcement in the final PDF document; for instance one can select one single rebar in the final 3D PDF file and see properties about the bar such as diameter, element ID in Revit, rebar type and some material characteristics; the information is accessible from the model tree tap, specifically from the properties region. The metadata is written in the *.idtf file using the method explained in the Section , so when the conversion to the U3D format is completed, this includes the complementary information. The U3D files can be embedded in a PDF document directly since they are natively supported by the PDF format see Section , in this manner a portable document can be created in a very simple way without the necessity of any further format conversion. In the case of this thesis, the alternative selected to create the 3D PDF files is the Movie15 package for L A TEX as it is described in the Section

90 The reinforcement model in PDF format 75 The above mentioned is why the 3DR application generates a L A TEX script, i.e. a *.tex file, which includes the respective U3D file created in a previous phase such as a movie in an empty document; this one is integrated by a A4 white page in which the 3D model is embedded. Likewise a set of default views is created in an auxiliary file in order to improve the visualization scenarios; the predefined views produced by 3DR are the most common required ones, more specifically: the four orthogonal possibilities, i.e. top, bottom right and left; and an isometric view. The program does not produce a 3D PDF file but it gives all the required tools to do it with the simple execution of the L A TEX script. The reason to not make it is that the current structure is more flexible, the script and the predefined views can be modified in order to improve them or to create documents with particular characteristics according to the project specifications. The complete structure of the process used for the creation of 3D PDF documents is sketched in the Figure 3.4. It is important to note that every time when the 3DR applications is executed, it creates a new set of files and delete the previous ones, whether these exist. Therefore it is not possible to combine in one PDF file the reinforcement models created in subsequence executions of the program, at least that a manual edition of the files is carried out assembling the IDTF files and converting them to the U3D format. 3DReinforcement API *.idtf *.u3d *.vws *.tex Latex *.pdf Figure 3.4: The process to create a PDF document for the reinforcement model using 3DR. In the end, the result is a 3D model in PDF format which contains the reinforcement model and the respective host elements; this is enriched with information about the properties of the rebar contained in the file. This kind of output alternative can be very useful in the practice, since almost every person with a computer, or an equivalent electronic device, is able to open and interact with PDF documents. Likewise, the flexibility of the auxiliary files is denoted since they can be used to assemble the 3D PDF file manually according to the particular requirements of a specific project; the aforementioned can be done by means of any commercial software able to create PDF documents in agreement to the PDF 1.6 specification, such as Adobe acrobat Pro 7.0 or superior. It is worth to say that the files produced during the process are written in standard and open source formats; therefore they can be modified freely by every user with knowledge and expe-

91 Integration of 3DR with the Revit reinforcing tools 76 riences in the corresponding data formats; this in order to improve them and, consequently, to increase the applicability of the files and the 3DR application itself. Figure 3.5: 3D Reinforcement model of a Beam generated with 3DR Integration of 3DR with the Revit reinforcing tools The structural detailing is a phase of the structural design process in which the model and its specifications are assembled together in order to produce a precise set of documentation, which will be used to recreate a physical version of the virtual model of the building. Taking a look at the structural reinforcement, creating the corresponding documentation can be a very complex and long task because of the huge amount to particularities and remarks required to complete successfully the manufacturing of the product, i.e. the reinforcing bars. The different tools provided by Revit Structure to carry out the documentation of the reinforcement were described briefly in the Section 2.4.1, summarizing, they are the following: Reinforcing bars (rebar) Area reinforcement Path reinforcement Additionally one can mention the specific functions of the Revit Extensions focused on reinforcing issues, which apply in particular conditions the previous tools in order to generate predefined reinforcement schemas. The Revit Extensions and can be used in the most common reinforcement cases and the reinforcement generated by them can be refined manually. In the same manner than the Revit extensions, the Revit API can be also included in the set of available reinforcing tools if a specific application is developed to complete reinforcing

92 3.2. 3DR Structure 77 tasks, and this is the case of 3DR. The main goals and capabilities of the program were explained previously in the Section 3.1, thus through this implementation of the Revit API several complicated and redundant assignments, concerning the generation of rebar, can be completed efficiently based on the information contained in the SOFiSTiK database. However the whole task of creating the structural details concerning the reinforcement cannot be completed using only one tool of the mentioned above. In fact the final documentation is produced by means of other complementary tools, such as annotations and visual customizations, but in order to be able to create these end output products, all the required rebar have to be placed in the model with the respective specifications obtained from the structural analysis, which in the case of this thesis is performed in SOFiSTiK. In this way, placing the rebar in the model becomes into a crucial task of the detailing process. The 3DR application is able to handle a big amount of the required work to accomplish the generation of the rebar but, as in the case of the Revit extensions see Section 2.3.2, 3DR was designed based on standard cases and usually every structure has some particularities that have to be solved locally by means of the basic reinforcing tools provided by Revit. So then, several sections of the structure are not supported by 3DR such as the complex connections, free form elements, critical points with respect to the results of the structural analysis and so on. Nevertheless the program was developed as a complementary tool for the already existing ones, thus placing rebar manually or by means of the Revit extensions is the way to produce a complete reinforcement model of the entire structure. Likewise, all the rebar produced by 3DR are enabled to be modified in order to improve them or adapted them to the special conditions and circumstances to which they are exposed. In other respects, it is very relevant for this thesis to note that traditionally the final output of the detailing process is a set of 2D drawings with distinctive characteristics to fulfill the specifications of the project, however the new technologies allows to experiment with new alternatives such as the 3D representations enriched with metadata; as it was described in the previous section, 3DR offers the possibility to explore the potential of the 3D output products in PDF format, however this option is also reachable by means of the IFC format. Revit supports the IFC definitions and through this way 3D models can be added to the final documentation of the project, even 3D PDF files can be generated using an IFC file as interface see Section 2.6.3, this task is carried out converting the graphical information stored in the IFC file to some natively supported format for the PDF standards, such as U3D. However the reinforcement is not mapped in the PDF s created using the commercial tools distributed with this objective, for instance Adobe Acrobat Pro. Hence this is a very god example of how the different tools provided by Revit Structure can be complemented by the 3DR application and vice versa, since the only capacity of it, with respect to the generation of 3D PDF documents, is the support of the reinforcement model DR Structure The programming structure of the 3DR application follows the guidelines of an external command according to the standards of the Revit API. This kind of scheme was selected in order to keep the programming work as simple as possible, since the graphical and esthetical

93 DR internal process 78 issues are not in the focus of this but the final result with respect to the 3D representation of reinforcement. In the following the basic structure of the program is described by means of a pseudo-code. 1 namespace Revit. Reinforcement 2 {... 3 public unsafe class Command : IExternalCommand 4 { public Autodesk. Revit. UI. Result Execute (... ) 5 { Transaction transaction = new Transaction (... ) ; 6 try 7 { AppProcess (... ) } 8 catch ( Exception ex ) 9 { return Autodesk. Revit. UI. Result. Failed ; } 10 finally 11 { transaction. Commit ( ) ; } 12 } 13 } 14 } Code Region 3.1: Global structure of 3DR as an External Command. As it is shown in the code region 3.1, only one transaction see Section is completed during the execution of the program, even whether several element are selected for the creation of the reinforcement the results will be committed just whether all the required rebar sets are created without problems, i.e. no sub-transactions are called in the development of the program. For instance if there is a problem reading the SOFiSTiK database the program would throw an exception, then it would return a message with some information about the problem and the transaction would not be committed; this is logic because it is not possible creating the rebar if there is not any information to define its properties, i.e. diameter, geometric location, material, among others. However a similar exception would occur whether some information is missing during the process, e.g. whether one element contained in the selection set is not included in the SOFiSTiK database, so in this case the transaction would not be completed as well. The next Sections are concentrated on the internal procedure that is accomplished by the application in order to produce the final output product, i.e. the 3D rebar DR internal process 3DR was designed to create a set of 3D reinforcing bars in several host elements following the specifications stored in the corresponding SOFiSTiK database. In order to complete successfully this task several specific assignments have to be completed in a strict order, in this manner the code region 3.2 illustrates the workflow of the application, which is embedded in the general structure of 3DR depicted in the code region // A p p l i c a t i o n p r o c e s s 2 SetConditions (... ) ; // Set i n i t i a l c o n d i t i o n s f o r the t r a n s a c t i o n 3 transaction. Start ( ) ; // S t a r t the t r a n s a c t i o n 4 // Scan the database o f SOFiSTiK i n order to get the i n f o r m a t i o n about the r e i n f o r c e m e n t 5 CreateSOFiSTiKDB (... ) ;

94 Working sequences in 3DR 79 6 //Loop over the s e l e c t e d element s e t 7 foreach ( Element elem in elementset ) 8 { 9 //Check whether the elements are v a l i d 10 AssertData (... ) ; 11 // Create the c o r r e s p o n d i n g rebar 12 CreateRebar (... ) ; 13 // Generate the IDTF model to r e p r e s e n t the r e i n f o r c e m e n t 14 CreateIDTFmodel (... ) ; 15 // Create a group to e n c a p s u l a t e the rebar 16 CreateGroups (... ) ; 17 } 18 // Create a U3D f i l e c o n t a i n i n g the r e i n f o r c e m e n t model 19 CreateU3D (... ) ; 20 // i f e v e r y t h i n g goes well, r e t u r n succeeded. 21 return Autodesk. Revit. UI. Result. Succeeded ; Code Region 3.2: Pseudo-code which ilustrates the application process of 3DR. Taking a look at the main cycle of the processing structure, one can note that it is started always testing the validity of the given elements, since the reinforcement only can be placed in a particular kind of host elements, as it is described in the Section Moreover the 3DR application is concentrated on simple elements hence complex connections and objects are out of the scope of the project, thus the test of the data contains these delimitations as well. The process can be organized in 3 big phases: the preprocessing, in which the application environment is configured; the processing, in which an internal loop leads the creation of the 3D reinforcement in both cases, the elements in Revit and the objects that will be stored in U3D format; an finally the close-processing stage, where, on one hand, the transaction is committed and, on the other hand, the U3D and complementary files used to create the 3D PDF see Section are created. The truly post-processing is developed outside of the 3DR environment with the help of the different tools provided by Revit Structure. In order to close successfully the transaction, all the phases of the process have to be completed without errors. Likewise the program considers an option to omit writing the files related to the production of the 3D PDF document through the continuous test of the value of a Boolean variable used as initial control of the corresponding methods Working sequences in 3DR The point of view used previously to describe the activities chain inside the 3DR application, detailed in the Section 3.2.1, does not allow a complete understanding about the particular tasks which the application actually solves. Therefore, trying to couple the different assignments in related activity groups the next classification can be established: 1. Set the initial conditions. 2. Read the SOFiSTiK database. 3. Create the internal data structures.

95 Set initial conditions Generate the Rebar. 5. Integrate the 3D PDF interface. One has to note that some activities are made simultaneously, such as the generation of the rebar and the 3D PDF files, however they correspond to different work branches and they are split in order to offer a better comprehension of themselves. In the following the required functions and algorithms developed to complete these assignments are described in detail Set initial conditions The initial conditions required for the correct performance of the 3DR applications are simply these two: setting the correct options for the failures in the transaction and activating the member supports check from the analytical model. The options for the failures in the transaction refer only to hide the warnings which are launched by Revit when the groups for the reinforcement sets are created. This problem occurs basically because the groups are created as empty objects and the elements are not added directly to them but in the other way around, i.e. the specific group is assigned to the respective elements; thus Revit does not take this assignation method in a very good way and considers that something wrong could be happening. By means of this special configuration, 3DR avoids that Revit shows a message box containing the warning during the execution of the program. However this task cannot be managed trivially and a complete new class has to be created in order to produce the correct structure needed to update the configuration properties. This new class has to inherit the properties of the Revit interface IFailuresPreprocessor, which is contained in the library RevitAPI.dll and is used to perform a preprocessing step to declare certain transaction failures as out of consideration. With respect to the second required condition, i.e. enable the member supports check; it has the objective to change the default structural settings in order to turn on the option: AnalyticalModelAutoCheckMemberSupports. This one provides the capabilities to retrieve, directly from the elements, information about their supports and consequently about which elements are used as supports. This data is essential to define the correct length and initial location of the rebar in the elements, since usually they are not isolated but connected to some other objects, thus some special conditions for simple connections can be taken into account Read the SOFiSTiK database The Class in charge of getting all the information about the model contained in the SOFiSTiK database has the name SOFiSTiK cdb, which implements the functions included in the DLL cdb w25 in order to retrieve the information, note that the number 25 included in the name of the library refers to the version of SOFiSTiK implemented during this master thesis. So then this object is integrated by two parts:

96 Read the SOFiSTiK database 81 The definition of the structures in which the data obtained from the database will be stored. The Class itself, where are included the methods to read and to store the information. Putting attention on the first part of the above mentioned entity, each time when a set of information is scanned from the SOFiSTiK database, such as nodes, beams, structural lines or reinforcement information, a particular memory space has to be decelerated to store it. These objects have to be defined according to the specifications enclosed in the SOFiSTiK auxiliary file CDBase.chm and sometimes can incorporate another objects as members. In this manner, every block of information retrieved from the SOFiSTiK database requires a public unsafe struct to be stored and afterwards implemented in some specific methods of the program; the struct has to be declared as unsafe because the functions used to get the data requires as arguments the pointer of the object and, according to the specifications of the C# language, the only context in which this is valid is on a unsafe environment. 1 public unsafe struct cdb_node 2 { 3 public int m_nr ; //Node number 4 public int m_inr ; // I n t e r n a l node number 5 public int m_kfix ; // Degree o f freedoms 6 public int m_ncod ; // A d d i t i o n a l b i t code 7 public fixed float xyz [ 3 ] ; // Coordinates 8 }// s t r u c t cdb node Code Region 3.3: Struct used to store the description of nodes written according to the help file CDBase.chm. The second section of the object is the most interesting one, because here are developed the methods to read and retrieve information from the SOFiSTiK database. Thus it is possible to subdivide it into four regions according to the action range of the methods: Constructor. The name defines the region, the object is created and, by default, all the information concerning the reinforcement and the corresponding host elements which is contained in the SOFiSTiK database is stored in a set of members declared previously. The information is scanned using the methods written in the extracting methods region, so in this manner the data about nodes, reinforcement layers, sections, materials and all the other relevant is accessible through the SOFiSTiK cdb class. Extracting methods. This region is integrated by a collection of methods which are used to organize the extraction of the data contained in the SOFiSTiK database; thus they provide several methods to extract either the entire information or only some specific cells of the SOFiSTiK database, for instance there is a special method to extract the structural lines and another one is retrieving the sections. However these methods do not interact directly with the SOFiSTiK database but they only call the cdb methods in the appropriate order. Cdb methods. These methods implement directly the DLL functions contained in the SOFiSTiK library in order read the database. They can be considered such as a link to interconnect both libraries, i.e. the 3DReinforcement and the cdb w25 from SOFiSTiK. These methods utilize as resources the Structs created in the first part of the class to

97 Read the SOFiSTiK database 82 store temporarily the data and the return it to the caller method. The definition of the methods is illustrated in the code region 3.4; one can see that the pointer of the specific struct is an argument of the cdb function imported from the DLL, which is why the method has to be declared such as unsafe and the address of the Struct have to be fixed. 1 /// Get a node from the Database 2 private unsafe int CS_sof_cdb_get_node ( int pos ) 3 { 4 //Get l e n g o f the data s t r u c t u r e 5 leng = Marshal. SizeOf ( node_01 ) ; // node 01 denotes the s t r u c t to s t o r e the data 6 fixed ( int * add_01 = &node_01. m_nr ) 7 fixed ( int * add_02 = &leng ) 8 // C a l l the c o r r e s p o n d i n g DLL f u n t i o n to get the data 9 return sof_cdb_get ( index, 20, 0, add_01, add_02, pos ) ; 10 } Code Region 3.4: Method implemented to retrieve the data about a single node. Note that an auxiliary fixed pointer is needed to complete the operation. DLL functions. The last region is composed just by three functions, which are imported as static external functions directly from the corresponding SOFiSTiK DLL. The capacities of these functions are very basic but at the same time are enough powerful to satisfy the necessities of the 3DR application, they only can open, close and get information from the SOFiSTiK database. 1 #region Import functions from DLL 2 [ DllImport ( pth_dll ) ] 3 private static extern int sof_cdb_init ( string datei, int p ) ; 4 5 [ DllImport ( pth_dll ) ] 6 private static extern void sof_cdb_close ( int index ) ; 7 8 [ DllImport ( pth_dll ) ] 9 private static extern unsafe int sof_cdb_get ( int index, int Kwh, int kwl, int * data, int * DataLen, int pos ) ; 10 #endregion Code Region 3.5: Functions implemented by 3DR to manipulate the SOFiSTiK database. Taking a look at the specific function to extract data from the SOFiSTiK database, this one is just a generic method and can be used to retrieve all the different blocks of information contained into the database. This is achieved by means of the given arguments, in this manner the two input values are the most relevant: on one hand the key value, which indicates the type if information that will be retrieved; and on the other hand, the specific struct appointed to store the data, this one has to correspond to the key value and the size in the memory has to fit with the specifications detailed in the CDBase.chm file, otherwise the information cannot be stored and an error will be returned. There are more functions available in the cdb w25 library which allows completing several different tasks, such as writing and locking the database, however they are not on the interest of the project but also they could be considered as a different way to interchange information

98 Create the internal data structures 83 between Revit and SOFiSTiK, i.e. establishing interoperability between the software in an even more direct way. So then, when an object of the class SOFiSTiK cdb is created, the above explained routines are executed successively in order to collect all the information contained in the SOFiSTiK database, which is relevant to the generation of the reinforcement for a structure. The produced object can be defined such a reinforcement virtual databank based on the SOFiSTiK database. To finish with this small overview of the scanning process of the SOFiSTiK database, it is worth to mention that all the information obtained from the database can be accessed through a set of public members, stored as List entities, by any external instance which creates and initializes an object from the class SOFiSTiK cdb Create the internal data structures When the term internal data structures is mentioned, it is difficult to have a good understanding of its real meaning. In the application process of 3DR, this concept is applied to the virtual databank, composed by a set of List, Classes and Structs, developed to provide all the required data to complete successfully the generation procedure of the 3D reinforcement. Thus these elements are not encapsulate only in one single object but in a collection of different types of entities, which besides storing data, are able to organize the information and to lead some of the local sequences of activities during the execution of the program. However the Data base Class can be considered such as the rector of the internal data structures since this object creates and provides access to the most of the referred objects, likewise this Class exchanges essential data with the secondary objects that are not completely under its control. Summarizing lightly, the main activities developed for the internal structures, since this very general point of view, are described in the following points: Create the SOFiSTiK virtual databank. Read and Store in Lists the materials, rebar and hook types already presents in the Revit project. Provide auxiliary methods for the unit conversion and simple matrix calculations. Create the Structs that will be used to generate the rebar, in these ones the properties of the reinforcement are assigned to the corresponding equivalent elements contained in the Revit project, these values are founded on the SOFiSTiK database. Generate the required new materials which are analogues to the ones used in SOFiSTiK. Establish the new rebar and hook types based on the properties of the equivalent objects contained in the SOFiSTiK database. Organize the objects that will be used in the generation of the IDTF file, i.e. create them and stored them, and then bringing access to them in order to produce, in the

99 Generate the Rebar 84 end of the application process, the required set of files used to construct a 3D PDF document see Section SOFiSTiK Database Materials Rebar types Hook types Internal data structures Properties of rebar 3D PDF Geometry of rebar Reinforcement model Figure 3.6: Organization of the information flow in 3DR by means of the internal data structures. The objects here defined as a constitutive part of the internal structures are not even contained in one file, however they are coupled together in order to obtain a better organization and to transfer information between the different methods and Classes of the program. More than one time it was necessary the definition of some interfaces to enable the communication with all the instances involved in the divers tasks. This public interfaces are fundamental for the complementation of every loop of the application process see Section 3.2.1, especially in some particular assignments as the generations of the rebar groups and the IDTF model used to create the U3D file Generate the Rebar Creating the rebar in Revit Structure to represent the reinforcement of the concrete elements is the main goal of 3DR. However placing the rebar in the 3D model does not imply solving any complex problem, basically the method described in the Section has to be applied enough times to fill the host element with the required bars. What can be consider as true challenge is to provide the correct information to the specific method implemented to generate the rebar, with the aim to map the results of the structural design, performed in SOFiSTiK, into the reinforcement model. Before generating the rebar, there are another three tasks that have to be accomplished in order to have all the necessary tools to define the properties and attributes of the reinforcement, i.e. composing the set of materials, rebar types and hook types which will be used to establish the specifications of every bar included in the model. Thus 3DR implements one separate class for each one of the above mentioned definition data

100 Generate the Rebar 85 sets; the names of these classes are conveniently formed as follows: Materials x, Rebar types x and Hook types x. One should not confuse these objects with the storing structures, which were described in the Section , since they were designed just to determine the characteristics of the rebar and not to preserve this information. Therefore this group of objects can be considered such a set of translation routines from the SOFiSTiK storing language to the Revit declarative syntax, because they only get some data imported from SOFiSTiK and then they arrange it in some particular way that Revit can understand it and map it in the corresponding Revit project as an element with equivalent semantic meaning to the one contained in the SOFiSTiK database. The input units for these methods are the same used by SOFiSTiK in its database, since their arguments are obtained directly from this instance. However the output values, which are stored in the respective internal structure, are already passed with the predefined Revit units see Section by means of a simple direct conversion. Likewise, the methods under discussion start with a test phase in which they check whether an object with the same name already exist to avoid duplications and, if this is the case, they update the constitutive parameters of the object. It is important to note that the methods never delete the duplicated entities since probably they are used to define the characteristics of some elements contained into the model, and if they are erased then the references to them will be eliminated as well. Follow on the generation path of the rebar, once the specifications of the rebar are processed a new chain of activities starts, i.e. getting the necessary information to place the rebar. This data set is constituted purely by geometric definitions, not of the rebar but of the respective host element; this since the geometric definition of the reinforcement is contained in the internal structures as all the other information used to create it. Thus the determination of the auxiliary geometry implemented to establish the relative location of the bars is carried out through scanning the geometric description of the elements, more specifically getting the information about the 3D solids which define the objects. Revit makes use a boundary representation of the solids, which is why each one of them is integrated by several faces; in this way one can determinate the boundaries of the element in order to place the bars inside the influence region of the respective element. However when the structure becomes more complex, or in better words not so simple, the definition of the internal faces of the solids is modified by Revit see Section in order to couple the different elements of the model together. Therefore the geometry provided from Revit is not a reliable mean to estimate the location of the rebar inside the elements, since the information returned by the program does not depend on the element itself but on the surrounding conditions. According to the previous explanation, 3DR utilizes only the information about the position of the analytical denomination of the elements, in other words the non 3D data which define the configuration of the object. For instance, in the case of a beam, the program will only take from the Revit database the coordinates of the initial and final point. So then, assuming that the reinforcement will be created just parallel or perpendicularly to the driving direction of the element, the parameters which define the shape of the element are used to project a virtual face on the critical points of the object, i.e. an alternative face that reflects the real geometry of the element and not the one modified by Revit.

101 Generate the Rebar 86 The virtual face is mapped calculating the perpendicular distances with respect to the critical points; this one has a magnitude equal to the corresponding definition parameter extracted from the Revit project. The Figure 3.7 illustrates the generation of the auxiliary faces used for placing the rebar inside the element. Figure 3.7: Projection of critical points to generate virtual faces on a beam element. Sometimes this virtual face coincides with one included in the set of faces belonging to the particular element on study, especially when all the elements have only an orthogonal superposition, which is why 3DR includes both possibilities in order to reduce the computation time of the program. The virtual geometry is just a guide for the creation of the rebar, since the location of the bars is defined in SOFiSTiK with respect to some point of the element and there is not absolute coordinates available; nevertheless other option would have been using this relative position and integrate it with the coordinates of the nodes, thus the rebar could be created directly without any reference to the geometry in Revit Structure, considering that this possibility would imply creating a similar virtual solid. In this manner the required geometry to fulfill all the references of the rebar to the host elements is amalgamated. With this information and the one contained the internal structures to establish the properties of the rebar, these can be placed by means of the corresponding methods. Thus the subsequence tasks required to complete the creation of the rebar are enumerate in the following. 1. Select the specific type of element which will be analyzed, e.g. beam or column. One has to consider that the way how the geometry is stored depends strongly on the structural type of the element. 2. Assign the type of reinforcement that will be created according to the information retrieved from the SOFiSTiK database. This category refers to the number of reinforcement regions to be created along the element. 3. Generate the set of curves that will define the specific rebar geometry. In the simplest cases a single straight line is used to define the longitudinal reinforcement of a

102 Integrate the 3D PDF interface 87 linear element; but the same procedure is followed for the generation of transversal reinforcement as well. 4. Place the rebar according to the position of the reinforcement layer. In this point the information stored in the internal structures is called in order to set the rebar type which incorporates all the properties of a certain set of bars. 5. Change the rebar number and spacing properties to fit with the requirements of each particular element. This information was also calculated in the previous steps and is only accessed through a specific Struct that encapsulates the data to define the properties of one special type of element, in the same way as the geometric called in the previous stage. The process is repeated till all the collection of reinforcement layers, which are defined in the SOFiSTiK database, are created; besides the elements could be sub-divided longitudinally, as it was described beforehand, in order to produce reinforcement sections to change the properties of the bars during the develop of its geometry, i.e. adapting the rebar to the specifications of the structural design with the goal of produce more efficient results. Therefore the loop over the reinforcement layers is in fact a nested loop inside the reinforcement sections loop, said differently for every new section of bars a new set of layers will be created. When the predefined sections along the element are covered, then the reinforcement model of the entire element is completed and the application returns to the main loop over the selection set and creates a model group containing all the rebar objects produced for this particular element as it was described in the Section Then the loop starts again to repeat the same tasks till all the elements in the selection set have passed for it. In this manner the generation of the reinforcement is completed, and the change in the Revit project will be visible when the corresponding transaction is committed Integrate the 3D PDF interface The creating process of the 3D PDF file is running synchronously with the generation of the rebar, i.e. each time when one bar is placed into the model then a reflect of this element is mapped in an equivalent object which, after some procedures, will become into an 3D graphical entity of a PDF document, as it is detailed in the Section Trying to be very specific, the 3D PDF process starts in the definition of the internal structures, since the properties of the reinforcement, which will be attached as metadata to the rebar in the final representation, are stored here with the peculiar pseudo-xml format that is demanded for the standards of the IDTF format. This task can be divided in three phases: firstly generating the mesh that will be used to represent the rebar; secondly writing the auxiliary IDTF file with the information of the 3D reinforcement model, including the properties of the rebar; and finally, converting the previous mentioned file to the U3D format, incorporating in this phase the production of the other auxiliary files, i.e. the L A TEX script and the views file. Taking a look at the first phase, i.e. generating the rebar mesh, one has to consider that the geometry of the rebar in Revit is defined by means of a set of curves, which are calculated

103 Integrate the 3D PDF interface 88 by 3DR, and there is not information in the Revit database about the 3D aspect of the element in question. In other words, the visualization of the rebar in Revit is carried out in a lower level and it is not possible to have access to this information through the Revit API. Therefore it is necessary to develop an alternative 3D representation in order to generate a 3D graphic analogue to the one present in Revit, this with the goal of producing a IDTF model which is the base of the 3D PDF process. In this way, each rebar element is regenerated in a new equivalent mesh integrated purely by triangles, since the standards of the IDTF format specify this kind of representation see Section Thus the shape of every particular rebar is established using the set of curves contained in the rebar definition; likewise the sectional configuration of the bar is determined using the parameters of the rebar type, specifically the bar diameter, assuming that a circular cross section is used in every case, what is logic and understandable. The accuracy of the process depends on the number of line segments used to define the circular sections of the bars, the minimum needed to have comprehensive results is four and this can be augmented whether a very precise representation is wished. However a more accurate model also means more triangles in the elements, what can be translated as a bigger file size and longer computation time. Hence the refinement of the 3D bars is an important factor for the efficiency of the entire program, which is why 3DR does not declare by default a high number of definition lines for the cross sections of the bars, since the visualization of the elements does not improve too much using values larger than six or eight. The Figure 3.8 illustrates how the mesh of a single bar element looks and how the refinement can change lightly the appearance of the bar. Figure 3.8: Meshing of a longitudinal rebar to be included in the IDTF model.

104 Integrate the 3D PDF interface 89 In this manner, all the bars contained in the model are taken into count on the process and when they are mapped by Revit to create a rebar set, then a loop over the bar stars to generate all the cloned rebar required to fit with the original model. The computation of the mesh is performed by means of a hierarchical structure formed by 5 levels: 1. Vertex. Single points which are used to integrate the model. 2. Facet. Group of points used to define certain flat region or area of the element. This object is formed always by three members, since only triangles are acceptable to write the IDTF file. 3. Solid. This object is integrated by a set of faces; referring to the reinforcement model, each single bar and its corresponding projections or cloned bars constitute a solid. The solid object incorporates one member with the name solid info in which the properties of the bar are stored. 4. Model. The Model is a collection of all the bars, i.e. solids, associated to one host element in Revit Structure. The number of Models is equal to the number of elements included in the selection set. 5. IDTF Model. This category encompass all the rebar groups, i.e. the Models, that where generated during the execution of 3DR. The IDTF model is completed when all the elements contained in the selection set were enriched with the corresponding rebar, meanwhile the individual reinforcement models, created for each entity in the element set, are collected in an auxiliary List of models. Thus an object of the Class IDTF model is created to encapsulate all the reinforcement models, which will be included in the final IDTF file and consequently in the PDF document. The Class IDTF model includes a method destined to write the mesh in IDTF format and another one to convert this into the U3D format, these two are called subsequently just after the generation of the IDTF object. The writing method includes in its outputs, besides the graphical information, the metadata stored in the definitions of the solids in order to provide to the user additional information about the properties of the rebar, e.g. structural type, material type, rebar type and the specifications of the material. 1 /// Write the Model i n IDTF format 2 // Text b l o c k s to use during the p r o c e s s 3 string [ ] PredefineTextBlock = {... } 4 public void wrtite_idtf ( string file_name ) 5 { 6 // Create a w r i t e r and open the f i l e 7 TextWriter tw = new StreamWriter ( file_name ) ; 8 // Write group d e f i n i t i o n 9 for ( int i = 0 ; i < num_mesh ; i++) {... } 10 // Write node d e f i n i t i o n s 11 for ( int i=0;i<num_mesh ; i++) {... } 12 // Write r e s o u r c e d e f i n i t i o n s 13 for ( int i = 0 ; i < num_mesh ; i++) {... } 14 // Write shader Resources 15 for ( int i = 0 ; i < num_solids ; i++) {... }

105 3.3. 3DR in the context of interoperability // Write m a t e r i a l Resources 17 for ( int i = 0 ; i < num_solids ; i++) {... } 18 // Write shading M o d i f i e r s 19 for ( int i = 0 ; i < num_solids ; i++) {... } 20 // c l o s e the stream 21 tw. Close ( ) ; 22 } Code Region 3.6: The IDTF writing process illustrated by a pseudo-code. Once the IDTF file is written, 3DR implements the corresponding 3DIF library to convert the IDTF file into the U3D format with a simple sub-processing routine. The L A TEX script is created using a template in which the only variable values are the names of the other files involved in the generation of the 3D PDF document, i.e. the U3D and the views file. About this last one, it is written based on a template as well but the different points required to establish the coordinates of the views are calculated using the boundary boxes provided by Revit for each element, obtaining in the end a global boundary box for the specific reinforcement model. The data in the U3D file is organized according to the structure depicted above, so the same hierarchical tree can be seen in the final PDF file, with the exception of the first two levels, i.e. point and face. Thus the different regions of the model, including the host elements, can be hided or denoted with some special remarks according to the demands of the users DR in the context of interoperability The main propose of 3DR is the exchange of information between two software packages, in other words improve the interoperation between them, this one at certain level restricted to the scope of the project. We can consider that the data interchange is successful when the information contained in one program is reflected accurately in the other one. This mapping does not imply generating the same objects but analogue data structures which can be implemented in order to store comparable information. [Clason(2007)] The communication between the two software is the basis of the term under discussion, since interoperability is a concept founded in the BIM context, and in this universe the communication has to be constant, accurate and open. The adjective open refers to the compatibility of the data sources with respect to the implemented software, while the term accuracy is used to denote the reminiscence of the data mapped from one software environment to another. In this manner, the quality of the interconnection, established to fulfill the prerogatives of BIM, is a transcendental issue for the industrial applications, since the data has to be concordant between the different programs when it is exported or imported; i.e. all the models generated during the BIM process see Section 2.1 have to contain a common definition dataset with a consistent semantic meaning. Said differently, each model can incorporated additional information according to the specific aims of the host software, but they must be based on the same core data. [Steel et al.(2010)steel, Drogemuller, and Toth] By applying these concepts to the 3DR application, we can find this kind of interaction when the program reads the SOFiSTiK database and creates equivalent objects in the corresponding Revit project, these new entities have a different architecture compared to the one under

106 3.3. 3DR in the context of interoperability 91 which the SOFiSTiK objects were structured, hence they are defined collecting information from several objects and merging the data in a final Revit element, i.e. the rebar. Revit Structure Rebar SOFiSTiK Structural element Shape Location Nodes Section Number Rebar type Spacing 3DR Layers Reinforcement Rebar data Name Diameter Material Material Hook type Title Properties Figure 3.9: Mapping of the SOFiSTiK data into the corresponding Revit objects by means of 3DR. So 3DR maps the information contained in the SOFiSTiK databank, specifically the relevant data for the generation of the rebar, in order to produce a 3D representation of the reinforcement, which is consistent and faithfully respects the definitions of the pertaining entities delineated in SOFiSTiK. This last point is very important, since the precision in the exchange of data allows to justify automatically the selection of the shape and the properties of the elements created in Revit through the analysis performed on SOFiSTiK; besides of that, the 3D model can be edited and improved locally by means of the diverse tools provided by Revit, obtaining in this way a high quality representation, which can be used to produce different output products. Since the visualization issues are not a priority of 3DR because Revit Structure is able to handle with this task alone with very good results, 3DR is concentrated in transferring raw data from SOFiSTiK to Revit. This is, in fact, a mapping from data stored in one native file format to another, i.e. from the SOFiSTiK database *.cdb to the Revit project *.rvt. Once the data is successfully imported, and the user is able to interact with this new available information, then the interoperability cycle is completed, i.e. the references among the different internal objects that participate on the reinforcement design are settled and the final products are ready to be develop. Likewise 3DR applies the information just appended to the Revit project to establish a second interoperability relation, this time between the conglomerate SOFiSTiK-Revit and any PDF viewer, through the generation of the set of files described in the Section In this case, 3DR implements some alternative data formats in order to convert the information calculated during its execution to the standards of the PDF format. In this manner the reinforcement model can be used as a visual platform to share specific information about the project to all the parties involved into the building process, including the clients and final users. Even if interoperability is a technical concept generally applied to informatics systems, it can be extend to the interactions between people as well. Thus the human interoperability

107 3.3. 3DR in the context of interoperability 92 can be defined as the capability of two or more persons, or working teams, to interchange information between them in order to complete certain tasks together. Therefore 3DR can be considered as a tool which allows the exchange of information among different persons on the basis of the 3D PDF documents, since not only visual data is contained on them, but a part of the constitutive information of the elements is attached as metadata with the only goal of enable a better understanding of the specifications of the model by the final user of the file. In this context it is possible to state that, besides the clear and promising results about the generation of a 3D reinforcement model based on the data contained in the SOFiSTiK database, the most significant benefit of 3DR, with respect to the BIM process, is the establishment of interoperability conditions for more than one set of circumstances. Needless to say, opening communication channels among different Software packages enables extending the capacities of both programs and, consequently, provides more tools to the users in order to complete some specific task. Summarizing the concepts and applying them to the 3D reinforcement representation, it is important to remark that the generation of a reinforcement model is not an isolated task, which can be completed independently from the parallel activities developed in order to accomplish the building process, more specifically during the structural design phase. Therefore the referent information to the reinforcement has to be updated constantly across a well defined working structure; in the case of the 3DR application this functional scheme corresponds to the Revit-SOFiSTiK workflow. Revit Structure SOFiSTiK Extentions SOFiSTiK 3DReinforcement Interface Revit project 3DR SOFiSTiK DB 3D PDF 3D Rebar Documentation Figure 3.10: interface. Interoperability between SOFiSTiK and Revit Structure through the 3DR virtual

108 3.4. Limitations and restrictions of 3DR 93 In this manner, 3DR establishes a virtual interface, illustrated in the Figure 3.10, between the two software tools in question, in order to constitute an interoperability environment, restricted to the structural reinforcement in particular cases. This virtual interface includes several communication mediums among the different standard data formats implemented during the local process, obtaining in the end a data network from SOFiSTiK to Revit Structure, with a special connection to the final documentation of the project, and consequently to the final users, by means of the 3D PDF files. 3.4 Limitations and restrictions of 3DR The 3DR application is designed to work synchronously with SOFiSTiK and Revit Structure such as a communication channel in the direction SOFiSTiK-Revit, in this manner a continuous information flow is established integrating 3DR with the SOFiSTiK extensions for Revit Structure. Consequently every limitation experimented through the link established in the opposite direction, i.e. Revit-SOFiSTiK, will be a limitation for 3DR as well. The respective documentation of the limitations of the existing link between the software packages in question is depicted in the Section Likewise, once the data about the reinforcement is scanned from the SOFiSTiK database, the capability of 3DR to represent graphically the reinforcement is delimitated by Revit structure, since 3DR only gives specific instructions to execute, with a predefined schema, the reinforcement tools offer by Revit. Thus the final visualization of the elements is restricted to the own capacity of Revit to handle with this task. However 3DR includes an alternative to complete the visual definition of the reinforcement model, i.e. the 3D PDF documents. By means of this output product, the functions of Revit Structure are extended to construct a more universal medium to exchange information about the project. In the following the particular restrictions of the 3DR applications are depicted in order to complete a clear illustration of the competences of the program Delimitation of the applicability of 3DR The next points encompass the particular restrictions about the applicability of 3DR for the generation of a 3D reinforcement model in the context of the Revit-SOFiSTiK environment. 1. The supported diameters for the rebar are the most common used in Germany and their denomination is performed in the standard units, i.e. millimeters. The Table 3.1 illustrates the available diameters. 2. The only supported elements are structural columns and structural beams, likewise both have to be defined by a rectangular cross section and the material type of the elements has to be set on concrete. 3. The program can be only used in the sequence order specified by the Revit-SOFiSTiK workflow see Section 3.1.2, since the information has to be updated constantly in order to obtain consistent results. For instance, once a first loop is completed on

109 Delimitation of the applicability of 3DR 94 Diameter Area (mm) (cm 2 ) 6 0, , , , , , , , ,158 Table 3.1: Available diameters on the 3DR environment. the workflow, then some modifications can be implemented over the structural model in Revit, such as changes in the definitions of the loads or modeling different elements; at the same time there is an available SOFiSTiK database, then the program can be executed without problem but the properties and geometry of the rebar generated by 3DR would correspond to the structural design performed over the previous model exported form Revit Structure. Thus, according to the magnitude of the modifications, the reinforcement model can present just errors in the dimension of the bars or even placing rebar in wrong locations. 4. Every element contained in the selection set for the generation of reinforcement has to be included in the SOFiSTiK database as well. The SOFiSTiK extensions allow to export special regions or specific parts of the structure, hence the structural design is performed only on a restricted set of elements which will be the only enable group of objects to incorporate to the 3DR execution. 5. Creating the rebar can be performed in several stages, considering that the selected elements have to be included always in the SOFiSTiK database and that the information about the reinforcement design has to be assigned in SOFiSTiK. Thus the whole model can be analyzed and designed, and then the sections of the model in Revit which are required for the user to include the rebar can be enriched with it progressively. 6. Only standard and simple connections are in the capability range of 3DR because the joining between different elements can vary significantly and this thesis is focused on proving the capabilities of the Revit.NET API with respect to the creation of 3D reinforcement, therefore the particular cases are not taken into account. 7. The configuration of the rebar placed in the supported elements is also restricted to simple cases. The number and position of the bars is determined by means of the reinforcing layers included in SOFiSTiK and a different scheme cannot be incorporated, however it is always possible implement local changes using the conventional reinforcing tools offered by Revit Structure. 8. The elements which already have some rebar assigned cannot be included in the selection set provided to 3DR. This in order to avoid excessive overlapped rebar inside an element,

110 Compatibility with the new software releases 95 thus whether the reinforcement model is generated on a second time, the previously created rebar has to be deleted before executing 3DR. 9. In order to produce a 3D PDF document, a L A TEX implementation has to be installed in the computer. Thus the PDF file is created through the execution of one single command or pressing one button, however a minimum knowledge about the L A TEX environment can be very beneficial to improve the quality and applicability of the final PDF file, since the program is based on a simple template and small changes in the L A TEX script can improve considerably the visual experience of the receptor of the 3D reinforcement model. 10. The 3D PDF files contain only the rebar generated by 3DR and they can be produced only in the Revit-SOFiSTiK working sequence see Section It means that there is not an exporting function to produce a PDF file containing the reinforcement model, since the functions related to this task are fully integrated in the application process of 3DR and they utilize information obtaining during the execution of the application. 11. The auxiliary U3D file is produced every time after the execution of 3DR, thus whether the reinforcement model is created in several phases the file will be overwritten the same number of times and the final version will include only the rebar generated in the last execution of 3DR. The different U3D files can be saved manually but unfortunately the cannot be merged in order to assemble a global reinforcement model, this task could be completed using the IDTF files but it can be very time demanding and implies a high level of knowledge about the IDTF format and the 3DIF libraries. 12. In order to visualize correctly the 3D graphics contained in the PDF file, it is necessary to install a viewer that supports the PDF specification 1.6, e.g. Adobe Acrobat Reader 7.0 or superior. There are some problems with the versions 9.3.x of Acrobat Reader, but the current version supports fully the U3D models generated by 3DR. Summarizing, 3DR is focalized just in a set of particular cases and has a delimited range of action. The application tries to proof the capabilities of the Revit API with respect to the representation of 3D reinforcement. Thus a structural detailing process would include always a revision on the connection points and the general configuration of the rebar along the different host elements, implying a refinement of the results of 3DR by means of other reinforcing tools, such as the Revit extensions. Likewise the core of the program can be extended to apply it to many further specific cases, since the basic structures and algorithms are already developed. Thus the required programming work to increment the applicability of 3DR has to be focused on identifying the specific regions supported by the program and creating the reinforcement schemes which will be used to place the rebar in the Revit model Compatibility with the new software releases 3DR was developed under the standards of the current versions of Revit Structure and SOFiSTiK when the project started. However the technology in our days change very fast

111 Compatibility with the new software releases 96 and new releases of the software are common, in some cases even each year. In the case of 3DR, it can work perfectly combining Revit Structure 2011 and SOFiSTiK 2010, however new versions of both programs are already available in the market, i.e. Revit Structure 2012 and SOFiSTiK In principle it is not possible include the 3DR application in the additional modulus of Revit Structure 2012, however the new version of Revit Structure includes some improvements and the development of an accordant version of 3DR can be considered as valuable. Thus the following points summarize the enhancements of Revit Structure 2012 regarding the reinforcement representation. [Autodesk(2011b)] ˆ The multi-planer reinforcement is supported. ˆ The reinforcing elements can be placed in in generic model families. ˆ Accuracy improvement on the display of self-intersecting reinforcement bars. ˆ The stirrups beyond cover references are supported. ˆ Improvements in the visualization of rebar with a bend dimension. ˆ Progress in the Structural connection representation. ˆ Enhancements in the analytical model configuration. The main problem about the compatibility with the new versions occurs in the Revit API, since it presents some changes with respect to the one released in the year Thus there are basically three problems which have to be solved in order to include the application in the new Revit interface: 1. The structure of the *.addin file has to change according to the new standards, the new syntax is very similar to the previous one but some small changes in the required declarations make the original addin totally incompatible, the solution of this problem is trivial but has to be considered because the program even cannot be loaded without this update. 2. The NewRebar(... ) method does not exist anymore, consequently the most important part of the program is useless. The new Revit API implements equivalent methods which have to be included in the source code, therefore some programming work have to be made before a truly compatible version is available to interact with Revit Structure The geometric definition of the elements differs from the one in which 3DR is based. Essentially the available information is equivalent to the one required for 3DR, but the retrieving methods have to be adapted to the new structure used by Revit Focusing now to the compatibility with the new version of SOFiSTiK, this issue can be treated easier, since the problem is reduced to implement the corresponding library to import the functions that enable to open, read and close the SOFiSTiK database. However even whether

112 Compatibility with the new software releases 97 this modification is simpler than the one needed for Revit, some changes in the source code are required and a totally new compilation of the application has to be built. In the same manner, a particular version of the program could be created to implement it on a peculiar combination of software packages, such as Revit 2011 and SOFiSTiK The problem here would relapse on the link established in the direction Revit-SOFiSTiK, performed by means of the SOFiSTiK extensions, since they cannot work with mixed versions; however it is always possible utilizing the TEDDY files (*.dat) to generate the model on a user defined SOFiSTiK database. All this possibilities are in general quite complex and in consequence predisposed to present some errors during the process.

113 98 CHAPTER4 Use cases This Chapter presents the final results of the project through a set of examples, which illustrate the capabilities of Revit Structure regarding the 3D representation of structural reinforcement. Hence the different reinforcing tools provided by Revit are applied in order to generate the respective reinforcing bars in the selected host elements; nevertheless the main part of the reinforcement models was created by means of the 3DR application, what implies a previous analysis and design process in SOFiSTiK. Likewise, the advantages and applicability of Revit Structure and the 3D reinforcement models are on discussion during the development of this Chapter D reinforcement models and their applicability Traditionally in the AEC industry, the representation of structural reinforcement in concrete structures is carried out by means of a set of 2D drawings in which the specifications of the reinforcing bars are presented and described. Revit Structure allows to the users creating this 2D objects through the implementation of different detailing tools, such as section views and annotations, however in order to apply these functionalities a 3D reinforcement model has to be created previously. The generation process of the 3D reinforcement model is a complex and time demanding task that can require even more resources than the usual 2D representation, since besides the generation of the 3D model itself, the final output products, i.e. the 2D specifications, have to be completed; however one has to consider that the 3D entities created in Revit Structure not only contain geometric information, but a set of properties and attributes that define an n-d object. Therefore the generation of 3D models of the structural reinforcement implies an extension of the dimensionality of the reinforcing bars, as it is stated in the BIM concept. In the Revit-SOFiSTiK work flow, which is described in the Section 3.1.2, the results of the structural design are used to produce the required rebar in the corresponding elements in order to produce a 3D reinforcement model and, later on, to prepare the final output products which will be used as guidelines to build the physical structure. In this manner, the 3DR application enables the user accomplishing the generation of the reinforcing bars efficiently and respecting the results of the analysis and design performed on SOFiSTiK. Moreover, 3DR contributes with the final documentation of the project by means of the

114 Isolated elements 99 generation of a 3D reinforcement model in PDF format. This feature tries to add a different option to the set of standard outcomes produced to represent the structural reinforcement, since in the current working process, the 3D model is just used to create 2D output products and the third dimension of the model is not exploited thoroughly. This issue is explored more deeply in the Section 4.2. In the following several samples of 3D models and 2D representations of structural reinforcement are exposed in order to illustrate the different outcomes that can be obtained implementing Revit Structure. In this manner, as it was established in the scope of the project see Section 1.2, the study was developed in the context of the Revit-SOFiSTiK workflow and the 3DR application was used as a link between both software packages, in the direction SOFiSTiK-Revit. Therefore all the reinforcing bars created in the next examples were modeled in Revit Structure, then a structural analysis and design was performed in SOFiSTiK and, finally, the reinforcement was placed in Revit, either by means of the 3DR application or through a manual assembly Isolated elements The simplest case, in which the structural reinforcement can be created by means of 3DR, is the one where the elements are completely isolated, i.e. they are not connected to any other object. In this case the 3D reinforcement model does not need to be adequate to the special requirements demanded by the complex connections. The Figure 4.1 shows the 3D reinforcement created on an isolated beam through the execution of 3DR. This model contains different reinforcing layers and the diameter of the bars change along the beam in order to adapt it to the requirements of the structural design process, which was performed in SOFiSTiK. Figure 4.1: 3D reinforcement in a isolated beam. Once the reinforcement is created in the corresponding host elements, it can be used to generate diverse 2D representations in order to illustrate the specifications of the reinforcing bars. The Figure 4.2 shows a column and its respective fundament enriched with 3D reinforcement, likewise a standard 2D output drawing is attached next to it. The generation of these kinds of 2D representation can be carried out very efficiently in Revit Structure, since the details of

115 Isolated elements 100 the 3D reinforcement model are created automatically by the program; hence the user only has to define in which points to create them and to include the corresponding annotations. Figure 4.2: 3D reinforcement in a isolated Column and 2D section view. The previous Figure is also a good example of the integration of 3DR with the different Revit reinforcing tools, since the reinforcement in the column was created by means of 3DR, while the reinforcing bars included in the isolated foundation were generated using the Revit extensions. The detail of the foundation can be seen in the the appendix A. Likewise, assembling a 3D reinforcement model of single objects can be also a way to accomplish the reinforcement model of an entire structure. Since, the reinforcement can be incorporated to the individual elements, while the connection points can be modeled manually by means of the standard reinforcing tools provided by Revit Structure. In the same manner, special considerations or additional bars can be included to the reinforcement model created previously with 3DR or the Revit extensions. The complete set of specifications for the samples of isolated elements can be seen on the appendix A.

116 D Frames D Frames The 3D reinforcement model of bidimensional structures can be generated by 3DR as well. The 2D frames are basically treated exactly as isolated objects, with the exception of the connections between the different elements of the structure. These critical points are supported by 3DR, but the application can only interconnect the bars from one element to other and the complex cases have to be arranged manually. Thus, 3DR is able to identify the connection points among the supported elements in order to modify the development of the reinforcing bars to adapt them to the surrounding conditions, i.e. the boundaries of the reinforcing bars are adjusted with respect to the adjacent objects. Figure 4.3: Sectional view of 3D reinforcement in a continuous beam supported by a set of columns. The Figure 4.1 illustrates the reinforcement generated on a 2D frame composed by a continuous beam and a set of columns. In this case, the entire reinforcing model was created by means of 3DR and then Revit Structure was used to produce the 2D structural details. When the structures become more complex, the advantages of the 3D representations can be appreciated in a better way. Thus one can see that the detail of the connections between the beams and the column requires a better specification, since the simple sectional view, shown in the Figure 4.1, is not enough to mark correctly the specifications of the connection. Therefore the 3D model contained in Revit Structure can be used to create 3D views of the reinforcement in order to offer another perspective of the point in question and to allow a better understanding of the rebar specifications. One should take into account that this 3D representation does not replace the 2D specifications, which are required to define the physical characteristics of the reinforcing bars. An example of the diverse possible 3D views that can be generated in Revit Structure is presented in the Figure 4.4. In the same way, the rest of the structural detail concerning the bidimensional structure referred in this Section can be seen on the appendix B.

117 D Structures 102 Figure 4.4: 3D reinforcement in a connection point of a 2D frame D Structures The representation of reinforcement in 3D structures is a very complicated task due to the complexity of the connections between the structural elements. 3DR can be applied in these cases in the same way as it was described in the previous examples, i.e. generating the reinforcing bars for isolated elements or a set of them, even if they are not in the same plane; however the connections have to be refined manually in order to produce a high quality reinforcement model. Figure 4.5: Detail of connection in a 3D structure. Thus, once the 3D reinforcement model is created, a set of 2D specifications has to be

118 D Structures 103 produced in order to complete the documentation of the project. Nevertheless, in the case of complex structures, it means creating a big amount of sectional views and details, such as the one presented in the Figure 4.5, which will define the configuration of the rebar included into the structural elements. The more complex is the structure, the bigger amount of details is required to integrate the documentation of the project; what implies that the organization of the project documentation turn also complex, since several detailing sheets are needed in order to have access to the entire specification set of some particular point. Therefore, in these cases the 3D PDF can help significantly to improve the visualization and comprehension of the structural reinforcement. The Figure 4.6 shows the 3D reinforcement model of the structure on question, which was created using 3DR and can be embedded in any PDF document. The user can interact in real time with this 3D model, since the object enables to deactivate/activate the different layers and entities which conforms it, e.g. reinforcing bars or host elements. Figure 4.6: 3D Reinforcement model writen in U3D format. The entire group of structural details generated to illustrate the structural reinforcement in this example is presented on the appendix C.

119 Local reinforcement generation Local reinforcement generation When the size of the structure overtakes certain limits, it is not convenient any more to generate reinforcing bars for the entire model. This is mainly because of two reasons: on the one hand, usually the structures have several common elements with exactly the same characteristics but a different location, hence it is not necessary to produce one detail per each element or connection point, but only a set of unique details has to be generated; and on the other hand, the big amount of bars in the model can interfere visually each other and decrease the quality of the representation. Likewise, a more complex structure implies that there are more complex connections. Therefore the composition of critical connection points turns hard to elucidate because of the big quantity of bars converging at the same location, what produces conflicts in the interpretation of the 3D and 2D representations. In this manner, the local 3D representation of structural reinforcement is the appropriate solution in the cases under discussion. Thus, the reinforcing bars can be included in the points of interest and then the user must implement the different detailing alternatives exposed above in order to complete the documentation of the project regarding the structural reinforcement. Figure 4.7: 3D reinforcement generated locally on a connection point. The Figure 4.7 illustrates the case under discussion. After the generation of the reinforcement by means of the 3DR application, diverse 2D details and sectional views can be created in

120 Local reinforcement generation 105 order to enrich the required guidelines for the physical building. Likewise, 3DR offers the possibility to create a 3D reinforcement model per each particular location on the interest of the user. The 3D reinforcement models, such as the one presented in the Figure 4.8, are an interesting option to increase the information provided to the constructors, due to their flexibility and simplicity. As in the case of the 2D details, several 3D models can be generate in order to integrate the corresponding documentation, offering to the final user a combination of 2D and 3D representations, which facilitate and improve the building process. Figure 4.8: 3D Reinforcement model writen in U3D format. The 3D PDF s, or similar files, could even one day substitute, at least partially, the traditional 2D representations of the project specifications in the AEC industry; because they provides more and better information, which is both visual and semantic. The entire specification of the study case can be found on the appendix D.

121 4.2. The alternative 3D representation in PDF format The alternative 3D representation in PDF format The 3D reinforcement models generated in Revit Structure are used basically to produce a bidimensional specifications set, therefore the third dimension of the model is not exploit adequately since the outcomes are restricted only to two dimensions. One can take advantage of the 3D models sharing them completely, without the bidimensional restrictions, by means of the PDF format. In the context of the Revit-SOFiSTiK workflow, the 3D PDF files are an innovative tool employed to offer an alternative to the traditional 2D representation of structural reinforcement used in the AEC industry. As it was exposed in the Section 2.6.3, Revit Structure is not able to embed the 3D reinforcement model in a PDF document; however the 3DR application includes the required methods to complete this task see Section through generating an auxiliary U3D file and the implementation of the Movie15 package for L A TEX. The 3D PDF files produced by means of 3DR can be used to interchange information between the different participants of the project as well as guidelines in the physical building process. The data contained in the PDF files can be divided in two sets: The geometric definition of the elements. The reinforcing bars and their corresponding host elements are stored mapping the parametric information included in the Revit project in order to produce a 3D object that offers a visual definition of the objects in question. The properties of the elements. The 3D reinforcement model is enriched by means of metadata which describe the physical properties of the bars and host elements, such as unit weight, Young modulus and other material characteristics; likewise other essential attributes are incorporated to this set of definitions, e.g. bar diameter, Revit rebar type, Revit material name. Figure 4.9: Properties of 3D rebar and model tree in a PDF reinforcement model.

122 4.3. Limitations of Revit Structure regarding the reinforcement representation 107 In this manner the 3D reinforcement model in PDF format can be incorporated to the Revit- SOFiSTiK workflow and, consequently, to the BIM cycle. Thus, some possible applications of the 3D PDF models in the AEC industry could be: A marketing tool to exchange information about the model with clients who are not expertise in Revit Structure o simply does not have the Software. A new alternative in the building process to visualize the reinforcement and to indicate how the contractors should proceed in the different phases of the construction which are related to the topic. A complementary part of the specifications of the project, the 3D models can be added in order to offer more information to all the participants in the building process and, in this way, they could allow a better understanding of the project, obtaining with this, more informed, and consequently better, decisions. The 3D PDF documents can be very useful in the case of complex details, when the traditional 2D representation cannot describe clearly the specifications of the reinforcement. The 3D PDF s can also be considered as a way to complement the BIM process, since they increase the quantity of information shared in the BIM working cycle. They are in fact an alternative to interchange information, such as the IFC format, but with some restrictions and putting special attention in the visualization of the model, and then leaving in a second plane the contents related with the other dimensions included in the BIM concept. 4.3 Limitations of Revit Structure regarding the reinforcement representation Revit Structure is a SBIM software package and, consequently, its conceptual foundation is based on the BIM statements, which are currently in a constant development and are evolving continually. Therefore, Revit Structure adapts its platform to the BIM idea and some issues are still on development. With respect to the structural reinforcement representation, Revit Structure can be considered such as a very powerful tool with a high level capacity regarding the 3D modeling of the rebar. Likewise it can be applied to diverse cases with noteworthy and successful results. However, there are some questions that Revit Structure cannot handle adequately and limit its capabilities or, in the best case, these critical points make more complex the 3D modeling of the reinforcing bars. The next remarks encompass the restrictions and problems of Revit Structure regarding on the 3D representation of structural reinforcement. 1. Placing a rebar in a single element is a simple task that can be solved quickly and efficiently in Revit Structure, however when the same element is included in a complex structure, the special conditions inherent to the connection issues and 3D representation make the task very difficult to complete.

123 4.3. Limitations of Revit Structure regarding the reinforcement representation The multi-planer reinforcement is not fully supported yet. It is very common having rebar elements which have to be extended in more than one plane and Revit Structure cannot define objects of this kind, therefore they have to be split in order generate an equivalent representation. 3. The huge quantity of reinforcing bars included in a reinforcing model produce, invariably, a superposition of some of the bars, therefore developing a tool that can find and solve the interference problems is essential to create high quality 3D reinforcement models. Currently, the Revit extensions offer the possibility to search for interferences between bars see Section but the applicability has several restrictions. 4. The internal units in Revit are defined as a combination of the units established by the SI and one exception only for the length, which is measured using feet as it was described in the Section It implies that the derived units are atypical and the units have to be converted constantly whether some calculations are performed. Therefore different problems can occur during the execution of an application, such as accuracy errors, implementation of wrong units and increasing the computation time. 5. Revit defines the elements by means of a B-rep method, which has several advantages over CSG such as its high flexibility and a much richer operation set. However Revit Structure redefines constantly the geometrical structure of the elements, i.e. the isolated elements are clearly defined as a set of faces from the start point to the end point, but when the elements are connected to other ones, the program changes the boundaries adding auxiliary vertex or redefining the extension of the objects. In consequence, the geometry retrieved from the Revit project varies continuously and one should take it into account when this information is used to determine the geometry of the respective reinforcing bars. 6. The representation of connections between different elements is the critical point of the 3D modeling of structural reinforcement, since the elements are rarely isolated in the real structures. Thus at least simple connecting considerations have to be taken into account when a 3D reinforcement model is created in order to assemble a high quality 3D representation. However, the complexity of these joint points shows the primary limitations of the traditional 2D representations produced to illustrate the specifications of the respective entities on question, as well as the coming complications of the potential 3D reinforcement models. On the one hand, the complete set of 3D bars involved in the connection cannot be used to produce the corresponding 2D outcomes, since the reinforcing bars from other elements can produce visual noise and reduce the understanding of the point on interest. And on the other hand, the big amount of bars converging at the same point makes the 3D representation unclear, bringing the necessity to use several 2D section views and 3D visual points, which can show the different reinforcement layers corresponding to the elements involved into the specific connecting point. 7. There is not a Built-in method to determine the connected elements, i.e. the relations between elements have to be established indirectly by means of self defined functions or through obtaining the supporting elements of the specific objects; however these searching tasks are always complex and their computation can have high time costs.

124 4.3. Limitations of Revit Structure regarding the reinforcement representation Every change in the definition of the properties of a single rebar implies creating a new rebar type to avoid modifying other elemets with the same rebar type. For instance, adding a new bar diameter to the Revit project means creating a rebar type with the parameter of the diameter setting according to the specifications, however each little change in the characteristics of the bars, such as hook type, hook length or material, also means creating a new rebar type. In this manner, according to the size and complexity of the structure, the Revit project can include hundred of rebar types, even if the quantity of available diameters is not so big. Thus one should be careful with the quantity of information offered to the final users of the model, since an overloaded documentation is never desirable. 9. The exchange of information about the reinforcement is limited, since the IFC format cannot be used such as an effective link between Revit Structure and another software package, regarding the structural reinforcement. Concluding this Section, one can state that Revit Structure can be used perfectly to complete the whole task of the structural detailing concerning the reinforcement in concrete structures; however the process is not fully refined and it still presents some problems and complications. Many of these points can be managed by means of developing applications based on the Revit API, such as 3DR, and in this way increase the effectiveness and applicability of the functionalities provided by Revit Structure. Thus, Revit can be considered as a platform with many capabilities with respect to the 3D reinforcement representation, however the generation of a 3D reinforcement model entails to solve complex problems, thus the main capacity of Revit consists on offering the possibility of developing the necesary methods to solve these problems.

125 110 CHAPTER5 Conclusions This Chapter offers a discussion about the contents presented in the previous Sections of this master s thesis. The first part contains an overview across the topics developed along the master s thesis, asserting punctual remarks about the achievements and end results obtained during this study. The second part tries to encompass the final consequences of the project itself and also provides a vision of the possible development directions and future perspectives. 5.1 Sub-conclusions In the following, the Chapters included in this master s thesis are briefly summarized in order to emphasize their most outstanding delineated points. Likewise the most notable outcomes derived from the study of the particular subjects concerning each Chapter are mentioned, this in order to state the results obtained for the project Chapter 1: Introduction. The first Chapter establishes the context in which the master s thesis project was conceived. It brings an overview about the BIM process with emphasis in the role of the reinforcement representation, incorporating it to the structural detailing stage of the cycle. Likewise a superficial description of both software applications implemented in the thesis, i.e. Revit Structure and SOFiSTiK, is depicted since a point of view based on the BIM concept. Besides, this Chapter defines the fundaments of the Revit-SOFiSTiK workflow in order to establish the scope of the project and its delimitations. Likewise this Chapter includes a short overview about the general tasks that have to be solved with the view to complete successfully the generation of a 3D reinforcement model. In this manner, the essential idea behind the thesis is stated, which can be described as the integration of the Software packages in question by means of the Revit API, in the frame of the 3D representation of the structural reinforcement.

126 Chapter 2: Fundamental concepts Chapter 2: Fundamental concepts. The Chapter 2 encapsulates all the basic notions applied during the development of this master s thesis. In this manner, a light overview about the BIM concept, extended to the Revit-SOFiSTiK environment, is presented here in order to structure a cognitional scheme which will be referred during the complete development of the study. Some fundamental concepts, such as interoperability, are defined here and they are used as a point of departure to reach the objectives stated in the Chapter 1. Furthermore the fundaments of the BIM process, the basic technologies relevant to the generation of a 3D representation of the reinforcement, on the Revit Structure platform, are described carefully, specially these points that required a certain specific attention. Thus, the applicability of the reinforcing tools offered by Revit Structure, including the Revit extensions, is depicted by means of practical examples. It is worth to say, the main characteristics of the SOFiSTiK extensions, which were applied in order to link the Software in point, are documented and illustrated in detail, since they constitute a bastion of the proposed working process and participate actively in the definition of the range of cases in which the previously established activities flow is valid. Perhaps the most important Section of the Chapter is the one which refers to the Revit.NET API, since this was implemented such as a medium to establish a data network between SOFiSTiK and Revit Structure, i.e. it is the main instrument to fulfill the constituent prerogatives of the project. In this manner, a brief overview about the basic terms, which are indispensable for the development of applications based on the Revit API, is enunciated in this Section in addition with the explanation of the principal guidelines required to satisfy the cardinal aim of project, i.e. the 3D Representation of structural reinforcement, by means of the Revit programming interface. Bringing into focus the interoperation between different software packages, by means of the Revit API, the data contained in an external source can be incorporated into another system; and then some internal procedures can be performed in order to produce valuable information to complete the final objectives of the specific routines. In the specific case of this master s thesis, the data, which is relevant to the generation of a 3D reinforcement model, is retrieved from the SOFiSTiK database in order to incorporate it to the Revit environment. In other respects, this Chapter includes a Section dedicated to the knowledge under which is founded the generation of the 3D PDF documents. This task is one of the elements of the Revit-SOFiSTiK workflow; therefore it is automatically covered by the scope of the project. Thus a method to create a 3D reinforcement model in PDF format, based on open source technology, is described step by step. This procedure is just one possibility, selected basically because not any property technology is required to complete the assignment; however there are more available options and some of them are covered in the respective Section of this Chapter Chapter 3: 3DReinforcement: a Revit API implementation. In order to integrate Revit Structure and SOFiSTiK, according to the delimitations of the project, an application based on the Revit API was developed, i.e. the 3DReinforcement

127 Chapter 4: Use cases. 112 (3DR) program. In this way, a detailed description of the applicability, structure and limitations of the 3DR application is depicted in this Chapter, including a illustration of the final results obtained through the execution of the program, i.e. a 3D reinforcement model, both incorporated to Revit Structure and embedded to a PDF document well as. On one hand, the first contents of the Chapter are dedicated to explore the capabilities of 3DR with respect to the main objective of the master s thesis, i.e. generating a 3D Reinforcement model, as well as exposing the particular circunstances in which the application produces consistent and accurate results. And on the other hand, the internal operating sequences of the program are analyzed and explained, leaving the deep programming issues aside, with a high concentration on the process chains implemented during the execution of the program on point. It is important to remark that the main objective of the 3DR application is to prove the potential of the Revit API, specifically when it is applied to the 3D representation of structural reinforcement. Thus only standard and simple cases are fully supported by the program; however this bounded instances range is enough to evidence the capacity of the Revit programming interface to provide new production means and to improve the existing ones, focalizing always the development direction in the topic under discussion. Besides, the role of 3DR in the Revit-SOFiSTiK workflow, referring this to the reinforcing bars generation, is a significant point on focus, since the exchange of information in the direction SOFiSTiK-Revit is not currently supported by any software implementation; what directly implies a gap in the fundamental concept in which the complete Revit-SOFiSTiK framework is based, i.e. the BIM process. In this context, 3DR contributes meaningfully to establish a complete data network, respecting the restrictions of the project, between both software packages Chapter 4: Use cases. This Chapter illustrates the final outcomes that can be obtained in the Revit Structure environment with respect to the 3D representation of the structural reinforcement. The contents of this Chapter can be considered such as a set of final output products, which was created on the postprocessing stage of the Revit-SOFiSTiK workflow. The distinct samples included in this Chapter were assembled by means of the integration of the different available reinforcing tools included in Revit Structure, which conglomerates: the basic rebar placing, i.e. locating manually the required bars; the Revit extensions, applying only the functions relevant to the reinforcement; and the 3DR application as well. Finally the documentation, concerning the reinforcement, of the particular study cases is amalgamated and enriched by means of the 3D PDF documents created by 3DR. Likewise the entire Revit-SOFiSTiK framework, which contains the 3DR program, is put to the test, since all the characteristics of the reinforcing bars generated in the examples are defined using the calculations performed in SOFiSTiK. In this manner a complete depiction over the capabilities of the conglomerate Revit-SOFiSTiK, with regarded to the representation of the structural reinforcement, is rounded out and closed.

128 5.2. Final remarks Final remarks The work presented in this master thesis is grounded in the BIM concept implemented in the Revit-SOFiSTiK framework. Along the different Sections of the document, one can appreciate the amplitude of the capabilities of Revit Structure, regarding the creation of a 3D reinforcing model, and its applicability. The 3D representation of the structural reinforcement can be achieved in the frame of Revit Structure by means of a set of basic reinforcing tools, which in essence allows placing the rebar manually into the model. Thus Revit enables to locate the single reinforcing bars, or a set of them, in the desired position through a graphical interface, incorporating in this process all the necessary values to define the characteristics of the bars. However, the described approach does not consider the possible benefits that can be achieved with the aid of the Revit API, which constitutes one of the aims of this master thesis. In order to show the practical applications of the Revit system, several examples are presented with the intention to illustrate the different possible results that can be obtained through Revit Structure. On that score, the examples of 3D reinforcement included in this thesis were created by means of a combination of all the reinforcing tools provided by Revit, together with the particular application based on the Revit API developed for this thesis, i.e. 3DR. Thus the different samples presented along the master thesis try to depict how the structural detailing process can be accomplished using Revit Structure and SOFiSTiK, with a clear allusion to the field of 3D representation of structural reinforcement, but also with certain emphasis in the interoperability issues, which are relevant to the integration between the distinct software packages involved in the BIM process. Nevertheless the interesting results obtained regarding the documentation of the capabilities of Revit Structure, as an isolated entity, with respect to the representation of reinforcing bars in concrete structures, the principal achievement reached in the end of the master thesis is the integration of the Software in question, i.e. Revit Structure and SOFiSTiK, by means of the 3DR application. 3DR is designed to couple into the Revit-SOFiSTiK workflow, such as a direct link between the programs, with the aim of exchanging information and generating a 3D Reinforcement model available to any implementation required by the user; consequently it is heavily dependent on the underlying framework, since the program establishes a data network in order to articulate a virtual interface to transfer the information contained in the SOFiSTiK database to the Revit project, and this interface is only valid in the specific context mentioned beforehand. Likewise the information retrieved from the SOFiSTiK database can be consider only as a data source, since it does not contain all the particular information required to delineate the complete set of parameters that defines the individual samples of rebar, which constitute the reinforcement model. Therefore 3DR takes this raw data and calculates the necessary values to characterize each member of the system, said differently 3DR applies a predefined reinforcing scheme in order to configure the shape, aspect and properties of the reinforcement. So by means of 3DR, a significant amount of the required reinforcement to fulfill the demands of the structural design can be placed into the model, in the certainty of knowing that it was

129 5.2. Final remarks 114 defined with base on the results of the analysis performed in SOFiSTiK. In this manner, a continuous workflow is established, at certain level and focused to the issues relevant for this thesis, which consequently entails one step further in the direction of generating a fully integrated BIM process. Complementing the general outlook over the capabilities of 3DR, besides the above mentioned competences, the application also extends the functionalities of Revit Structure through the generation of standard PDF documents with embedded 3D graphics. 3DR implements the data computed during its execution, in order to create an alternative geometric representation of the reinforcement model, which is enriched with descriptive information about the properties of the particular reinforcing bars, this with the aim to assemble an integral specification of the reinforcement model and avoid restringing the PDF document only to the graphical issues as well. Thereby the 3D PDF files can be attached as a complementary part of the final documentation of the respective project, since they can improve the understanding of the project specifications as well as increase the quantity of information available for the final users. Likewise the PDF files are a convenient medium to interchange information, between different participants of the BIM process, since they are commonly used almost everywhere and constitute a multiplatform mean of communication. Whereby the interaction between the live entities which participate in the BIM process becomes simpler and more efficient as a consequence of the elimination of the superfluous details during the data transference. To conclude and synthesize the consequences of the master s thesis project, one can assert that notwithstanding the noteworthy potential of Revit Structure regarding the 3D representation of structural reinforcement, nowadays there is not any context in which a complete interoperability has been established among all the Software involved in the building process, therefore one has not achieved to concrete yet the ideal concept of BIM, and probably one will not be reached in the short term, this mainly because of the complexity that implies the exchange of accurate and consistent information between the different participating systems of the specific framework on the view. So then, the competences of 3DR enable extending the BIM action range to some particular cases, always in the Revit-SOFiSTiK environment, filling partially the gap between both Software packages by means of the data network mentioned beforehand. Likewise 3DR leads to several meaningful benefits respecting the representation of reinforcement, which correspond, on the one hand, to the ones that come together with the implementation of the BIM process and, on the other hand, to the possibilities and potential explored by the program regarding the production of a new set of standard outcomes implemented on the reinforcement model, i.e. the 3D PDF documents. In this manner, this study encapsulates the essence of the capacities of the combination of Revit Structure and SOFiSTiK with respect to the 3D reinforcement representation. This on the frame of the proposed workflow, establishing the limitations and advantages of this approach, and remarking along the paper the crucial significance of the interoperability notion, which can be considered such as a critical point of the BIM conceptual vision.

130 5.3. Outlook Outlook The domain of the results obtaining in the end of this master s thesis has well defined limits and, in general, the final products are comprehensive, since particular cases are not included in the scope of the project. Thereby, due to the fact of the wide range of distinct reinforcing schemes that could be applied to the specific cases present in the concrete structures, a particularization of the applicability of 3DR is the clearest development direction. Currently all the rebar generated through 3DR is based on a predefined reinforcing configuration, this one corresponds to the simplest case of reinforcement valid for the supported elements, likewise the geometric construction of these elements does not include any complex shape or definition. However these restrictions can be overcome with a high efficiency and in a reasonable time span, since the basic structures of the system are already integrated and only the peripheral components of the program should be on the focus of development. Nevertheless, extending the capabilities of the direct link between Revit and SOFiSTiK, which was written for this thesis, i.e. the 3DR application, has an insurmountable constraint which cannot be ignored: the link is only valid in the context of the Revit-SOFiSTiK workflow. Thereby, in order to increase the interoperability conditions between the different Software packages involved in the building process, several specific links would be required; moreover they should be specialized in the diverse range of structures and elements utilized in the AEC industry. In this line of thinking, the IFC exchange format looks as an interesting option, which should be explored before continuing with the development of particular solutions that can be applied only locally; considering always that the complete sphere of the BIM technologies is currently under development and an optimal interoperability will not be reached in a short period, which is why software implementations, such as 3DR, can be considered as valuable in the short and medium term. In other respects, the potential of the 3D PDF technology is also a point to analyze considering the future perspectives, since the transference of information by virtual means to the branches of the building process closer to the physical construction, still has to be integrated to the BIM process. In the case of the work done for this thesis, an alternative 3D representation of the reinforcement model in PDF format, fully dependent on the proposed workflow, opens the door for a wide-range of implementation with the aim of improve the visual understanding of the project specifications. Since Revit is not able to export the model as a PDF file, the inherent capabilities of this type of documents is abandoned, at least that supplemental tools, such as 3DR, assist the procedure. Consequently, the development of an independent application, which can carry this task out, is one of the further additions regarding the above mentioned particularization of the functionalities of 3DR.

131 BIBLIOGRAPHY 116 Bibliography [Adobe Systems Incorporated(2006)] Adobe Systems Incorporated. PDF Reference, version 1.7, URL U3D Supported Ele- [Adobe Systems Incorporated(2007)] Adobe Systems Incorporated. ments. Hemisphere, (April):1 49, [Adobe Systems Incorporated(2009)] Adobe Systems Incorporated. Adobe PDF - Quick overview of PDF file format, URL developer/tips/topic_tip31.html. [Autodesk(2007a)] Autodesk. Revit Structure Interoperability with AutoCAD, 2007a. URL [Autodesk(2007b)] Autodesk. Revit Structure and BIM, 2007b. [Autodesk(2010a)] Autodesk. Revit Extensions for Revit Structure 2010, 2010a. URL http: // [Autodesk(2010b)] Autodesk. Autodesk Revit Structure 2011 User s Guide, volume 123. June 2010b. URL [Autodesk(2011a)] Autodesk. Revit 2011 API Developer s Guide. 2011a. URL autodesk.com/adsk/servlet/index?siteid=123112&id= [Autodesk(2011b)] Autodesk. Autodesk Revit Structure, 2011b. URL revitstructure. [Buchgraber(2010)] Gerald Buchgraber. Enriching PDF 3D documents with semantic metadata from multiple sources. Master thesis, Graz University of Technology, [BuildingSMART(2011)] BuildingSMART. Model - Industry Foundation Classes (IFC), URL model-industry-foundation-classes-ifc. [Clason(2007)] John Clason. Building Information Modeling : Value for Real Estate Developers and Owners by. Master thesis, Massachusetts Institute of Technology, [ECMA International(2007)] ECMA International. ECMA-363 Universal 3D File Format, URL Ecma-363.htm. [Ernstrom(2006)] J.W. Ernstrom. The contractors guide to BIM. Associated General Contractors of America, [Evans(2011)] David Evans. PostScript vs. PDF, URL features/psvspdf/index.html.

132 BIBLIOGRAPHY 117 [Fingerloos(2011)] Frank Fingerloos. Beispiele zur Bemessung nach Eurocode 2. Ernst & Sohn, ISBN [Grahn(2009)] Alexander Grahn. The movie15 Latex Package, [Hejnfelt and Oksengaard(2007)] Thomas Hejnfelt and René Oksengaard. The use of 3D and BIM technology for structural analysis and design. Master thesis, Technical University of Denmark, URL [Intel Corporation(2005)] Intel Corporation. IDTF ( Intermediate Data Text File ) Format Description, URL [Legrand(2010)] Damien Legrand. Detailing of Reinforced Concrete and Steel Connections with AutoCAD Revit Structure. Technical report, Autodesk University, [Leung(2011)] Francis Leung. Autodesk Revit Structure 2011 Training Handout. Technical report, [Liebich(2011)] Thomas Liebich. Die Auswirkungen von Building Information Modeling auf die Leistungsbilder und Vergütungsstrukturen für Architekten und Ingenieure sowie auf die Vertragsgestaltung. buildingsmart, URL [Maunula(2008)] Antti Maunula. The Implementation of Building Information Modeling (BIM).A Process Perspective. Master thesis, Helsinki University of Technology, [Microsoft Corporation(2010)] Microsoft Corporation. Debugging external application, URL /debugging-external-application. [Nielsen and Madsen(2010)] Anne Kathrine Nielsen and Søren Madsen. Structural modelling and analysis using BIM tools. Master thesis, Aalborg University, [Robinson(2007)] Clive Robinson. Structural BIM: discussion, case studies and latest developments. The Structural Design of Tall and Special Buildings, 16(4): , doi: /tal. URL [Seifert(2008)] André Seifert. BIM im Planungsprozess-Gebäudedatenmodell und Kostenermittlung. Master thesis, Bauhaus-Universität Weimar, [SOFiSTiK AG(2011a)] SOFiSTiK AG. SOFiSTiK Extensions for Autodesk Revit Structure, 2011a. [SOFiSTiK AG(2011b)] SOFiSTiK AG. SOFiSTiK Basisfunktionalitäten, 2011b. [Steel et al.(2010)steel, Drogemuller, and Toth] Jim Steel, Robin Drogemuller, and Bianca Toth. Model Interoperability in Building Information Modelling. Software and Systems Modeling, [Suhr(2011)] Roland Suhr. Untersuchung der Möglichkeit einer Durchgängigen Tragwerksplanung Anhand eines Virtuellen Gebäudemodells nach der Idee des Building-Information- Modeling. Master thesis, Hochschule Darmstadt, [Sullivan(2009)] Michael Sullivan. Utilizing Autodesk Revit Structure to Model and Document Concrete Reinforcing. Technical report, Autodesk University, 2009.

133 BIBLIOGRAPHY 118 [Weir et al.(2010)weir, Richardson, and Harrington] Thomas Weir, David Richardson, and Jamie Harrington. Mastering Revit Structure John Wiley & Sons, ISBN

134 119 APPENDIXA Structural detailing in isolated elements A.1 Simply supported beam A.1.1 Design parameters Element properties Value Units Height 0,60 m Width 0,30 m Total length 5,00 m Table A.1: Parameters in relation to the properties of the element. Figure A.1: Simply supported beam with a under the action of a line load. Load case Value Units Direction Dead load -15,0 KN/m z Live load -10,0 KN/m z Table A.2: Load system applied on the element.

135 A.1.2. Structural Details 120 Material properties Value Units (Concrete) Material name C40/50(DIN ) - Type Concrete - Young Modulus 31400,00 M pa Shear Modulus 13100,00 M pa Unit Weight 25,00 KN/m 3 Concrete compresion 35,00 M pa Poisson Modulus 0,20 - Table A.3: Material properties of the host element. Material properties Value Units (StructuralSteel) Material name B 500 B (mod) Betonstaal - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 76923,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 500,00 M pa Poisson Modulus 0,30 - Table A.4: Material properties of the Reinforcing bars. A.1.2 Structural Details Figure A.2: Top view over the simply supported beam on question.

136 A.1.2. Structural Details 121 Figure A.3: Section view over axis 1. Figure A.4: Cross section of Beam on axis 1.

137 A.1.2. Structural Details 122 Figure A.5: 3D reinforcement in a isolated beam. Figure A.6: U3D Reinforcement model of a Beam generated with 3DR.

138 A.2. Isolated column and foundation 123 A.2 Isolated column and foundation A.2.1 Design parameters Element properties Value Units Height 0,60 m Width 0,40 m Total length 5,00 m Table A.5: Parameters in relation to the properties of the element. Figure A.7: Left:Isolated column and foundation. Right: equivalent SOFiSTiK model. Load case Value Units Direction Dead load -50,0 KN z Live load 10,0 KN/m y Table A.6: Load system applied on the element.

139 A.2.2. Structural Details 124 Material properties Value Units (Concrete) Material name C40/50(DIN ) - Type Concrete - Young Modulus 31400,00 M pa Shear Modulus 13100,00 M pa Unit Weight 25,00 KN/m 3 Concrete compresion 35,00 M pa Poisson Modulus 0,20 - Table A.7: Material properties of the host element. Material properties Value Units (StructuralSteel) Material name BSt 500 SA (mod) - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 76923,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 500,00 M pa Poisson Modulus 0,30 - Table A.8: Material properties of the Reinforcing bars. A.2.2 Structural Details Figure A.8: Cross section of the Column on question.

140 A.2.2. Structural Details 125 Figure A.9: 3D reinforcement in a isolated Column and 2D sectional view. Figure A.10: Detail of foundation under isolated column.

141 126 APPENDIXB Structural detailing in 2D frames B.1 Design parameters Figure B.1: Continuous beam and equivalent SOFiSTiK model. Load case Value Units Direction Dead load -10,0 KN/m z Live load -5,0 KN/m z Table B.1: Load system applied on the elements. Beams properties Value Units Height 0,40 m Width 0,30 m Total length 3,00 m Table B.2: Parameters in relation to the properties of the beams.

142 B.1. Design parameters 127 Columns properties Value Units Height 0,30 m Width 0,30 m Total length 3,00 m Table B.3: Parameters in relation to the properties of the columns. Material properties Value Units Material name C40/50(DIN ) - Type Concrete - Young Modulus 31400,00 M pa Shear Modulus 13100,00 M pa Unit Weight 25,00 KN/m 3 Concrete compresion 35,00 M pa Poisson Modulus 0,20 - Table B.4: Material properties of the host element. Material properties Value Units Material name BSt 500 SA - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 76923,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 500,00 M pa Poisson Modulus 0,30 - Table B.5: Material properties of the longitudinal reinforcing bars. Material properties Value Units Material name Baustahl - S275 - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 81000,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 275,00 M pa Poisson Modulus 0,30 - Table B.6: Material properties of the transversal reinforcing bars.

143 B.2. Structural Details 128 B.2 Structural Details Figure B.2: 3D reinforcement in a continuous beam supported by a set of columns. Figure B.3: Sectional view of 3D reinforcement in a continuous beam supported by a set of columns.

144 B.2. Structural Details 129 Figure B.4: Top view of continuous beam. Figure B.5: Standard cross section of the beams which integrate the 2D frame. Figure B.6: 3D detail of foundation under a column.

145 B.2. Structural Details 130 Figure B.7: 2D detail of connection between the beams and a supporting column. Figure B.8: 3D detail of connection between the beams and a supporting column.

146 131 APPENDIXC Structural detailing in 3D structures C.1 Design parameters Beams properties Value Units Height 0,50 m Width 0,30 m Total length 6,00 m Table C.1: Parameters in relation to the properties of the beams. Columns properties Value Units Height 0,50 m Width 0,30 m Total length 4,00 m Table C.2: Parameters in relation to the properties of the columns. Material properties Value Units Material name C40/50(DIN ) - Type Concrete - Young Modulus 31400,00 M pa Shear Modulus 13100,00 M pa Unit Weight 25,00 KN/m 3 Concrete compresion 35,00 M pa Poisson Modulus 0,20 - Table C.3: Material properties of the host element.

147 C.1. Design parameters 132 Figure C.1: Analytical model and load system on 3D structure. Load case Value Units Direction Dead load -15,0 KN/m z Live load -5,0 KN/m z Wind load 5,0 KN/m x Table C.4: Load system applied on the elements.

148 C.1. Design parameters 133 Material properties Value Units Material name BSt 500 SA - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 76923,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 500,00 M pa Poisson Modulus 0,30 - Table C.5: Material properties of the longitudinal reinforcing bars. Material properties Value Units Material name Baustahl - S275 - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 81000,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 275,00 M pa Poisson Modulus 0,30 - Table C.6: Material properties of the transversal reinforcing bars.

149 C.1. Design parameters 134 Figure C.2: Bending moments M y calculated by SOFiSTiK. Figure C.3: Shear forces V z calculated by SOFiSTiK.

150 C.2. Structural Details 135 C.2 Structural Details Figure C.4: Top view of 3D structure. Figure C.5: Standard cross section of the beams which integrate the 3D structure.

151 C.2. Structural Details 136 Figure C.6: Sectional view of 3D reinforcement in x direction. Figure C.7: 2D detail of connection point between two beams and one column.

152 C.2. Structural Details 137 Figure C.8: 3D view of connection point between two beams and one column. Figure C.9: 2D detail of foundation under a column.

153 C.2. Structural Details 138 Figure C.10: Sectional view of 3D reinforcement in y direction. Figure C.11: 2D detail of connection point between a beam and a column.

154 C.2. Structural Details 139 Figure C.12: 3D reinforcement model of the entire structure.

155 140 APPENDIXD Local structural detailing in 3D structures D.1 Design parameters Beams properties Value Units Height 0,60 m Width 0,40 m Total length 6,00 m Table D.1: Parameters in relation to the properties of the beams. Columns properties Value Units Height 0,40 m Width 0,40 m Total length 3,00 m Table D.2: Parameters in relation to the properties of the columns. Material properties Value Units Material name C40/50(DIN ) - Type Concrete - Young Modulus 31400,00 M pa Shear Modulus 13100,00 M pa Unit Weight 25,00 KN/m 3 Concrete compresion 35,00 M pa Poisson Modulus 0,20 - Table D.3: Material properties of the host element.

156 D.1. Design parameters 141 Material properties Value Units Material name BSt 500 SA - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 76923,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 500,00 M pa Poisson Modulus 0,30 - Table D.4: Material properties of the longitudinal reinforcing bars. Material properties Value Units Material name Baustahl - S275 - Type Structural Steel - Young Modulus ,00 M pa Shear Modulus 81000,00 M pa Unit Weight 78,50 KN/m 3 Yield Stress 275,00 M pa Poisson Modulus 0,30 - Table D.5: Material properties of the transversal reinforcing bars. Load case Value Units Direction Dead load -30,0 KN/m z Live load -20,0 KN/m z Table D.6: Load system applied on beams. Load case Value Units Direction Dead load -25,0 KN z Live load -10,0 KN z Wind load 10,0 KN/m y Table D.7: Load system applied on columns.

157 D.1. Design parameters 142 Figure D.1: FE model generated in SOFiSTiK. Figure D.2: Bending moments M y calculated by SOFiSTiK.

158 D.2. Structural Details 143 D.2 Structural Details Figure D.3: Top view of 3D structure.

159 D.2. Structural Details 144 Figure D.4: 3D reinforcement generated locally on a connection point. Figure D.5: Isolated elements of 3D reinforcement generated locally on a connection point.

160 D.2. Structural Details 145 Figure D.6: 3D local detail on a connection point. Figure D.7: U3D Reinforcement model of a connection generated with 3DR.