Revit Categories....

While mapping our assembly classification from Uniformat II to OmniClass Table 21 I needed the list of Revit object categories. This is only a part of that 200+ entry list that can be accessed upon exporting Revit model to ODBC.

Id	Name
-2000011	Walls
-2000014	Windows
-2000023	Doors
-2000032	Floors
-2000035	Roofs
-2000038	Ceilings
-2000080	Furniture
-2000100	Columns
-2000120	Stairs
-2000126	Railings
-2000151	Generic Models
-2000160	Rooms
-2000170	Curtain Panels
-2000171	Curtain Wall Mullions
-2000180	Ramps
-2000190	Filled region
-2000191	Plan Region
-2000340	Curtain Systems
-2000700	Materials
-2000996	Shaft Openings
-2001000	Casework
-2001040	Electrical Equipment
-2001060	Electrical Fixtures
-2001100	Furniture Systems
-2001120	Lighting Fixtures
-2001140	Mechanical Equipment
-2001160	Plumbing Fixtures
-2001180	Parking
-2001220	Roads
-2001260	Site
-2001300	Structural Foundations
-2001320	Structural Framing
-2001327	Structural Beam Systems
-2001330	Structural Columns
-2001336	Structural Trusses
-2001340	Topography
-2001350	Specialty Equipment
-2001354	Structural Stiffeners
-2001360	Planting
-2001370	Entourage
-2003600	Spaces
-2008000	Ducts
-2008003	Duct Tags
-2008010	Duct Fittings
-2008013	Air Terminals
-2008015	Duct Systems
-2008016	Duct Accessories
-2008020	Flex Ducts
-2008037	Electrical Circuits
-2008039	Wires
-2008043	Piping Systems
-2008044	Pipes
-2008049	Pipe Fittings
-2008050	Flex Pipes
-2008055	Pipe Accessories
-2008075	Telephone Devices
-2008077	Nurse Call Devices
-2008078	Nurse Call Device Tags
-2008079	Security Devices
-2008081	Communication Devices
-2008083	Data Devices
-2008085	Fire Alarm Devices
-2008087	Lighting Devices
-2008090	gbXML Surface
-2008099	Sprinklers
-2008101	Switch System
-2008107	HVAC Zones
-2009000	Structural Rebar
-2009003	Structural Area Reinforcement
-2009009	Structural Path Reinforcement
-2009010	Structural Path Reinforcement Symbols
-2009013	Rebar Shape
-2009030	Structural Connections

Cool Revit add-on for a hot summer

After living through the negative effect of the thermal lag in a non-insulated masonry building during my vacation on one of the Adriatic islands, I wished that the architect designing this, in all other aspects beautiful family residence, had the access to this latest add-on for Revit platform.

Great job Autodesk for this technology transfer between Revit and Ecotect Analysis!

Revit - Ecotect Surface subdivision improvements

Thanks to Jon, and his post on the improved curtain wall workflow in Revit Architecture 2010, we can see how one can significantly improve geometry translation process when analyzing building's skin within Ecotect Analysis.
Keep burning that Midnight Oil Jon!

VE-WARE goes live

The Revit integrated VE-Ware is now ready for download . VE-Ware presumably gives instant feedback on a building's energy consumption and CO2 emissions based on real geometry and using international climatic data. Over the next few weeks we will test this application and see how it compares to a range of already existing free applications and services that can be used for the preliminary Building Performance Analysis.

Revit Architecture 2009 to gbXML – Problematic Structure

Last week, one of the students in my course on BIM tools for sustainable design created a model that had an excess of shading surfaces and as such was rejected by Green Building Studio as invalid geometry. In order to remedy that I suggested that the same model could be processed within Revit Architecture 2009 since, as I have mentioned before, it has the ability to strip the model of excess shading surfaces. At that point this seemed like a good idea, right? Wrong. The model, which had been 4 MB in size, grew to be 48 MB in size and needless to say it was not applicable for simulation. We submitted the XML file to GBS for their analysis, and this is what they found:

	RAC 2008	RAC 2009
int.floor	232	3965
int.wall	232	305
ext.wall	376	8830
roof	3	665
raised floor	183	650
ceiling	0	2
shade	924	863
und.wall	40	2068
und.slab	33	1066
opening	1311	1457
spaces	76	86

This morning I decided to put a simple model created in RAC 2008 to the test and, since I suspected that having the structural elements might have something to do with XML output, I placed a simple round (pay attention to the word “round”) concrete column in the center of this test structure. Analysis of the 2008 XML file did not show anything unusual, so I proceeded and opened the same file in RAC 2009. Not to my surprise the newly generated 2009 file quadrupled in size and these are the findings:

	RAC 2008	RAC 2009
slab.grade	1	32
roof	1	32
ext.wall	4	36

The round column is being defined with 32 segments, and just for the future reference when modeling curvilinear geometry think of the polygon count, as even in these BIM days it still matters.

The conclusion is that the structural element is subtracted from theroom volume, the void is therefore tessellated, and surface type enumerators are assigned to the newly generated surfaces. Interestingly the enumerator for the vertical faces is the exterior wall, and this poses an alternate problem related to the overall calculated mass of the analytical model. Now, although in both versions of RAC the structural element is designated as Room Bounding, somehow RAC 2008 was semi-smart about it and it was ignoring them, where RAC 2009, possibly due to the enhancements with the room object, is quite happy in exporting those structure bound faces as well as exponentially increasing the size of the gbXML file.
In order to make previously created RAC models applicable, one should declare all of the structural elements as non Room Bounding and by simply doing this the gbXML output from RAC 2009 will be almost identical to the one from RAC 2008. This will increase the usable room area within the project, but we can all agree that this is the small price to pay for being green, or maybe not?
The only slight difference in the file size will be caused by the changed nomenclature within the 2009 generated XML file that is used for more eloquent description of exported surfaces.You can download both the 2008 and 2009 samples and their corresponding XML files by following this link.

Revit 2009 - Smart about shading surfaces

The Revit 2009 line of products offers some rather nice improvements in regard to the structure of the gbXML file, as well as in regard to how the geometry is translated into the same.
The first visible improvement starts with Energy Data entry within RAC 2009 Project Information options. The user will have the option to define the ground plane location and project phase as well as the “Sliver” tolerance, which specifies the tolerance for areas that will be considered sliver spaces.
But to me the most interesting one is the ability to specify whether the exported analytical model will contain "Shade" surfacesTypes enumerators or not. If the decision is made to export the model without Shade surfaces, the resulting gbXML file will represent pure space/volume analytical geometry, stripped of any intended or unintended "Shade" surfaces.

In the case that you really don’t care whether the addition of "Shade" surfaces will offset your results, go ahead and turn on the "Shading Surfaces" option, and voila, they are back whether you like them or not. This opens the possibility of manually merging the non "Shading Surfaces" model with only those shading surfaces that are welcome in your analysis, like eaves , overhangs, and various tectonic elements that will impact the insolation loads.
The following workflow describes one possible way of merging both gbXML files by using GBS’s VRML browser and a suitable XML editor like XML Marker.

Export two gbXML files: one with "Shade" surfaces turned off and one with "Shade" Surfaces turned on.
Submit the one with "Shade" surfaces to GBS and look at it in the VRML viewer. Examine the surfaces whose name contains “depx” as part of their description and this will help you identify those that you are willing to keep.

Once those surfaces are identified, in the XML editor open the file containing "Shade" surface, copy the entire surface(s) definition, and paste them by appending those after the last element definition in the gbXML file that does not contain any of the “Shade” surfaceType enumerators. Save the modified file and compare the results.

If you work with a relatively small building these results will not be noticeable, but as the scope increases and the complexity of the structure increases, as well as the need to switch from generic building elements to those that have real world thickness, the difference between these different Shading Surfaces options will become more evident.

gbXML Project Location and Revit

Location, location, location! These days, even with the real-estate market in peril, this seller’s mantra should still be relevant for anyone that is serious about their energy modeling practice and Revit’s model translation. When exporting your model to a gbXML compliant file, according to the Revit Architecture manual, all you need is the ZIP code and the building type. Well, not quite so as unfortunately, even though the latitude and longitude data is exported to gbXML, it does not relate to the project’s zip code but to the location that is determined via the advanced model graphics settings. And since the DOE 2.2 manual clearly states that hourly loads are the function of a building’s longitude and latitude one should take that extra step of synchronizing the ZIP code and sun location within Revit before translating Revit’s building geometry. Or, we can just hope that in one of the next installments of Revit BIM platforms the sun data and energy data will be automatically synchronized. You can easily verify the inherit discrepancy that is described above by opening the newly created gbXML file and verifying the “Campus” entries of the ZIP code, longitude and latitude.

IES Revit Architecture 'Plug in' Now Available

IES is pleased to announce it has developed a free plug-in to Autodesks Revit Architecture which provides a direct link to its software and to the companys new architect-orientated Toolkits.
(Read more...)

Download the plug-in....

Revit to gbXML - What does the window want to be?

As I was finishing my tutorial on manually placing shade devices as part of Revit's model envelope, I stumbled across this rather interesting "feature" that was exhibited while translating geometry into the gbXML file format. But before I continue to describe that particular Revit to gbXML behavior I need to make a correction to a statement in my previous article where I was testing Revit's ability to model shading devices by using In-Place families.

"Shading devices, constructed or planted, exterior or interior, can be approximated in Revit's BIM model via the persnickety use of a variety of modeling objects, but within Revit Architecture there is no identifier that designates any such improvisation as a valid gbXML compliant Shade surface. Someone might ask, but what about using a roof or a slab family to create exterior shading devices? Sounds like a good idea, but unfortunately to export such an element, the same one should be a part of a room bounding enclosure."

I need to praise Kyle Bernhardt for pointing out that this statement needs to be revised as follows: In Revit Architecture one can use Floors or Walls (stick with generic) to represent the shading surfaces. The Walls and Floors that are of the System Family type will get exported, but if you attempt to model them as In-Place families they will be ignored.
This means that any articulated solid extrusion made as an In-Place Wall or Floor will not be exported to the gbXML file.
Nevertheless in order to successfully export the objects mimicking Shading surfaces into the gbXML file, the warning message stating that a particular Room Bounding element is ignored should be disregarded and one can proceed with saving a new gbXML file.
Now back to glazing.
In order to test the available Window families and their corresponding operational (descriptive) parameter within the Revit Building Model, place an array of different window families along one wall in a sample model in order to see if the translated output will properly identify these windows according to the Window Type identifiers that are outlined within gbXML schema version 0.34.
Those Window type identifiers are as follows:

• FixedWindow
• OperableWindow
• FixedSkylight
• OperableSkylight
• SlidingDoor
• NonSlidingDoor
• Air

When building a model, if you resort only to Window families for facade apertures it really does not make any difference what type (Casement, Fixed, Awning, Glider etc.,) is used, as all of those will be translated with the "OperableWindow" gbXML type identifier.
The opposite in this glazing interpretation is that all of the Wall Family based glazing (Curtain Walls, Storefronts) is always translated with the "FixedWindow" gbXML type identifier.

The ability to eloquently articulate glazing performance in any building submitted via gbXML for analysis can not be regarded as accurate if the designer does not have the utmost control over the ventilation character of glazed surfaces. Unfortunately, within Revit Architecture we do not have the capability to designate windows operational descriptor, which means that the Curtain Wall family based glazing will always be simulated as non operable, whilst the Window family based glazing will always be characterized as operable type glazing.

One quick way to remedy this is to identify an element's ID and use it's value to parse and edit the gbXML file before is submitted to Green Building Studio for further analysis.

To mimic the sentiment of people that are trying to use Revit Architecture for Building Performance Analysis, it is quintessential to make some functionality changes to Revit's Room Object and make it behave more like the eSpace objects in Autocad Architecture where all of the relevant gbXML type identifiers can be directly assigned to the analytical space and its bounding elements such are walls and openings.

Revit Architecture 2008 - Review

...it is important for BIM vendors like Autodesk to continue to invest some of their resources into broader R&D efforts rather than on simply improving what they have developed so far. The latter is undoubtedly important for day-to-day usability but it is the broader research and development that will lead to real innovation and ultimately shape the future of BIM.

Reed the entire article

by Lachmi Khemlani, 27th of June 2007

An interesting survey for Revit Building users

Revit Building 9 has just been released but the team is working hard again. Follow this link and help them with a survey tackling another workflow idiosyncrasy of the Revit Building BIM platform.

http://www.surveymonkey.com/s.asp?u=665082150566