In the past I have written posts about the links between Revit and CSC Fastrak and the links between Revit and Robot these posts have generally pointed out more problems than solutions. Unfortunately, this post is more of the same.
I still maintain a view that the bi-directional link between analysis packages and Revit will not work fluently, this was exposed when I trialled Revit and Robot interoperability, it can be read about in the post above, and there are extensive discussions from myself on AUGI. Despite my thoughts on bi-directional interoperability, I do still see a benefit in linking analysis software to Revit.
In the past I have used CSC Fastrak to create a “throw away” model and set of rough and ready documents for concept design, the ability to use an existing model and easily knock up a set of plans, elevations and sections is a huge time saver. Concept designs change that much anyway it makes sense to create a “throw away” model and start from scratch once the design is firmed up.
I don’t see any added value beyond concept for bringing a model into Revit from an analysis package for a number of reasons, but mainly because of the simplification of dimensions for analysis tools. A package like Robot or ETabs doesn’t need to know that a beam is offset 25mm from grid. However, I do see real added value in going in the other direction depending on the complexity of the building in question. If a time saving can be made by building a Revit model first then exporting into an analysis package I strongly believe we should be taking advantage of that efficiency. In this post I am going to take you through my findings when going from ETabs to Revit.
This came about with a project that had been modelled in ETabs but documented in AutoCAD, I cannot name the project or show any images of the project but it involved 2 36 story (approx) towers coming down onto a podium level with 4 or 5 stories below the podium. There was a desire to get the model into Revit so the people involved in the project could take a closer looks at the facade framing which was fairly complex in nature.
My initial idea was to simply import the ETabs model into Revit using our default template file and see what the results are.
During the import process some elements automatically mapped, meaning that the CSiXRevit tool was doing its job, other elements only stated “use default,” at the time I could only assume that during the import process further elements would be created and mapped.
The whole process took a good 4-5 hours, once the import was complete the results were interesting to say the least.
- A total of 21,101 errors
- 17,979 Element join errors
- 3050 Line too short errors
- 32 Point Load errors
- 40 Wall Errors
and a huge database log file containing a lot of error messages.
Having said that, I was left with a Revit model, the geometry was there despite the members being incorrect. The few concrete members that mapped automatically were all the same size and all other framing members were steel.
The next step was to let the CSi Exchange tool do all the work, after all the CSi documentation does say that:
|Steel Sections||Will be mapped to equivalent Revit Structure sections. Will be loaded if not already loaded.|
|Concrete Sections||Equivalent Revit Structure sections will be automatically created and mapped (See note 1)|
To facilitate the mapping of concrete sections, it may help if you have the various Revit Structure sections already loaded before you import your ETabs model into Revit. If CSiXRevit cannot easily map the names, then you can set the mapping at time of import. If you would like CSiXRevit to be able to automatically create equivalent Revit members of families you must load at least one member of the family for CSiXRevit prior to import.
|Walls||All wall geometry and openings will be created in Revit Structure|
There is a table in the CSi guide that shows the naming of the families that have to be loaded into the Revit template prior to import, these are essentially the out of the box families;
To save myself another 4-5 hours for the second trial I set up a beam family within the Revit template named in accordance with the CSiXRevit documentation and purged out all other families from the project file. This would allow me to see whether or not the CSiRevit tool could automatically create framing members as suggested above.
The simple answer to that question is no it can’t, it did map one type of concrete beam and again made every other concrete beam exactly the same.
The third and final attempt was to create every single element type that was contained in the ETabs model, the trick for automatic mapping of elements is to create the element within Revit and make sure the name is exactly the same as the name within ETabs, or so i thought……
- 364 Frame Sections (Beams and Columns)
- 36 Floor Types
- 24 Wall Types
One thing I noticed during this process is that within ETabs individual member definitions aren’t only constrained to the size of the member, material is also taken into account. This means you could easily have 3 concrete beams that are exactly the same size, but all have different names because the material is different. This process was quite cumbersome but once complete I felt confident the import process would be a success. (how wrong I was)
The third attempt was complete with 13,599 element join warnings, and a total of 6972 warnings from CSiXRevit itself.
Unfortunately there isn’t a happy ending to this story, after leaving my machine on overnight for the import to take place, and waiting another 2-3 hours for the element join warnings to be resolved and the model to regenerate I was left with this
Absolutely nothing………. The model geometry is clearly visible behind the CSiXRevit warning dialogue box, but once Revit has worked through its ‘issues’ all the geometry vanishes, the file size stays exactly the same as the initial template file, and thankfully I wasted no time because I left the machine working in the background and overnight.
I do still believe there is a place for the link between Analysis and design software such as Revit, but my opinion as stated at the start of this article is that place should be going from Revit to analysis software, I went through the process above because of need rather than want, it was required to assist a current project rather than an R&D exercise because I saw true benefit in doing this.
I will however be undertaking a thorough R&D exercise going the other way, from Revit to ETabs in the near future, I will share the good, the bad and the ugly parts of my findings once that process is complete.