Friday, October 26, 2007

ACADIA

In these days of BIM this often overlooked, but still very relevant, organization is an excellent source of a vast theoretical knowledge on the implementation of digital technology in architecture. It is definitely worth joining, even in the case that you only want to get their annual conference proceedings. If you really want to know where BIM is coming from, ACADIA is the place to start.

Monday, October 15, 2007

Clerestory - or not so clear....

It is undisputable that glazing is a crucial element of a building's envelope and from that perspective the kind of glazing that is implemented on a project can greatly contribute (or not so) to the overall thermal and day lighting characteristics of a building.So what do we have to do within Revit in order to be able to depict the most accurate aperture configuration of one’s preliminary design? First we need to take a look at the way Revit is interpreting objects like Windows, Store Fronts and Curtain walls when embedded within a wall opening and exported to a gbXML file. When you start modeling in Revit, do yourself an enormous favor and forget about anything else bur Generic Family types, and for all the practical purposes stick with generic walls, slabs, roofs, windows and doors, as none of their construction characteristics are conveyed to GBS via gbXML. One of the undocumented idiosyncrasies of Revit’s interpretation of openings is that any glazed component of a buildings skin is being exported to gbXML as an OPENING of a “FixedWindow” type, and nothing would be wrong with that at the schematic design analysis if that interpretation was modeling style (family) independent. Well it is not.While modeling a series of case studies for future training material based on several past projects, the quintessential architectural element the clerestory window became a point of confusion for Revit’s gbXML translations.Take a look at these two models. In both cases the overall size of the structure and the relative position of the building objects was unchanged, but in the first case the clerestory glazing has been represented by an object from Store Front Curtain Wall family ands in the second case it has been represented by an object from Window family.
When the Store Front Curtain Wall object is used in the same location it is ignored by gbXML translation and the host surface does not contain the opening child element associated with it.


Launch this VRML model file to highlight and examine its surfaces in order to visualize clerestory inconsistency.


In the second model I have replaced the Clear Story element with a window object and it has been correctly translates as the child opening surface to the hosting exterior wall



Launch this VRML model file to highlight and examine its surfaces and see that clerestory is reported correctly.



The recommendation of this finding is to use the Window Family objects as often as possible in order to represent the glazed openings in building skin, and the only modification that I would suggest is to modify the generic window family and assign height and width as the instance parameters. This will allow you to manipulate a stretchable element within the walls as a very good modeling alternative to Store Front style curtain wall.
It is worth mentioning that the first floor store front was in both instances reported correctly as 4 different glazed surface which also can be used as an additional argument to use the Window object , as none of the mullions are exported to gbXML, and the more analytical surfaces are pushed to GBS simulation site the more complex and slower simulation will be.
A very good reference for anybody that is building a model suitable for the preliminary energy analysis is the
GBS manual and following the best practice procedures that are outlined there one should, from the start, avoid building intricate models with complex skins, as well as most of the geometry such as overhangs, brise de soleil, or double skin facade.
In the next post I will explain how to modify gbXML file in order to compensate for Modeling Software shortcomings when shading elements are the essential part of a building envelope.



Monday, October 08, 2007

CompliCAD / BIM

This article is a bit on a cynical side, but maybe, just maybe the cynicism is what we need for a sober look at which path to take before a commitment to the change has been made.
Again, understand your process before is rendered obsolete!

CompliCAD by Scott Meckenzie

Tuesday, October 02, 2007

ACA - Ductwork - Part II

Even though there is an excellent tutorial on creating ductwork out of structural elements, posted by Archidigm, I could not resist and give ACA (former ADT) walls a chance to prove their versatility.
With little bit of profiling and sweeps manipulation, one can easily modify a wall style that allows for some rather convenient placement of the proxy ductwork within a BIM compliant model.
As with any other ACA object that employs curve liner shapes, its representational quality will greatly depend on FACETDEV variable setting.
Download the sample file and see if this technique could work for you as well. Needless to say that with some additional classification and the creative use of Property Set Definition, these ducts can go a long way.




Click on the image to launch Design Review

Even though there is an excellent tutorial on creating ductwork out of structural elements, posted by Archidigm, I could not resist and give ACA (former ADT) walls a chance to prove their versatility.
With little bit of profiling and sweeps manipulation, one can easily modify a wall style that allows for some rather convenient placement of the proxy ductwork within a BIM compliant model.
As with any other ACA object that employs curve liner shapes, its representational quality will greatly depend on FACETDEV variable setting.
Download the sample file and see if this technique could work for you as well. Needless to say that with some additional classification and the creative use of Property Set Definition, these ducts can go a long way.


Sunday, September 23, 2007

Revit – a "Shade" too green - Revealed !


Well the shades are still there but thanks to Revit’s management and development team, the explanation for their occurrence was given promptly. In this instance Revit’s team (I just do not like to call them the factory as in my view programming is anything but a metaphor for Modern Times), has proven once again that they pay the attention to their product and the people using it. So “Shades”, here we go. From now on you can think of them as a “negligible” artifact that is the result of overlapping polygonal geometry when host and hosted elements interact.

(image courtesy of AutoDesk)

Think of this “negligible” factor within gbXML file as your comfort level threshold when it comes to the accuracy of GBS simulation results. As illustrated these shade surfaces are formed from the centerline of Revit’s wall to the exterior surfaces of either walls or roof eaves.
Their depth depends on the construction type and the amount of overhang, meaning the thicker the exterior wall the deeper the shade surface, and the wider the overhang the larger area of that roof's surface will be designated as the Shade surface.

(image courtesy of AutoDesk)


Therefore the difference in the amount of applicable shading will be different with respect to the construction method as a 12” wide wall over 10 feet will produce an additional 5 SF of shading, and a 24” thick wall over the same distance will generate 10 SF of shading surfaces. For now, if you seek for a no questions asked simulation model, go ahead and get rid of all of the Shade surfaces that are not functional from the designer's perspective by manually deleting them from the gbXML file.The good news is that Revit's team is working hard to streamline the gbXML translation tool even more by increasing its accuracy and flexibility.
It is also important to emphasize the relationship between the Room object and its upper boundaries.
This subject is covered in
Revit’s MEP white paper and it deals with a limited range of roof forms and the required relationship with Room objects.
To make this long story short, one should ensure that the Room object’s upper boundary extends above the highest vertex of the roof. The analytical volume that is reported to gbXML file is not the one that reflects Room object's volume but the one that is encapsulated by the boundary surfaces of the adjacent building elements.I would encourage everyone to open their gbXML file and examine its content from time to time and verify that all of the model elements are correctly exported from Revit’s model. If reading XML is not one’s cup of tea, the GBS client has a convenient tool that translates the gbXML file into a VRML model and indicates the potential conflicting analytical surfaces. This model can be easily shared online and in order to visualize it the user should install a VRML viewer such as Cortona by Parallel Graphics.




In the next post I will illustrate some basic building forms and the best strategies for schematic design zoning in order to achieve quick and usable comparative results from GBS simulation.

Sunday, September 02, 2007

Revit – a "Shade" too green !

Over the last few years we have used a variety of the available tools to conduct basic energy analyses of our designs. At the scale of building components a valuable tool of the trade has been LBLN’s Therm 5.1 (6.1), which was able to relatively accurately predict the thermal transfer relationship among various building components and materials. On the whole building scale the two tools of choice were Ecotect and Green Building Studio.
Recently, due to its format’s legibility, it became evident that Revit Architecture has some issues when it generates the gbXML file.
The first one is that if a user attempts to poke through the Light Fixture schedule this somehow partially triggers Revit’s MEP mode where it starts outputting Light Fixture and Equipment Loads in a room, but does not assign value to those and they are being reported to GBS as zero values, making your building internal loads no believable.

The second issue that we ran into was the inaccuracy of the gbXML file in terms of additional building components being added by Revit. I am taking about “Shade” devices that are showing as part of the gbXML file for every Wall and Roof object within the Revit model. It is interesting that the same Object ID from Revit’s model is used on both Polygons describing Wall and Shade respectively.

As a result the output from your simulation can be skewed as being more or less energy efficient depending on the building’s location and construction method.
The only way to circumvent this problem is to manually open a Revit generated gbXML file and look for “Shades” that are not supposed to be here as the part of the original design. Identify them, delete them and rerun the simulation and compare your results.

Here is the example of what I am talking about. This extremely simple model where the generic 8” wall, Generic 12” Slab and Generic 12” Roof are used with the Room volume calculation enabled and with the Room object having enough offset to be picked up by Roof planes.





The output file was than examined and the intriguing addition of the addition surfaces is quite evident. The additional “Shade” surface type enumerators are not part of the original design as they do not relate to any “floating” wall geometry.


What is even more intriguing is that when Object IDs are compared throughout the gbXML file, one notices that a single Revit object was interpreted twice: once as a building object designated by surface type enumerator whose value = "Exterior Wall", "Roof" "Slab on grade" etc.) and simultaneously as the non design existent “Shade” object.
To check the validity of the object's ID number I have used the number from the same gbXML file to select an object within the Revit model.

In this day and age when so much focus is directed toward BIM compliant software ‘s ability to be used as an appropriate analytical tool it is quite disconcerting when these glitches occur. Most of the results that are obtained from these models might have embedded errors that were not design envisioned but software altered, and the confidence that architects can have in their design by expressing it in an quantifiable way should not be compromised by launching software that claims more than it can deliver.

Furthermore, it is high time for software developers to start thinking as architects and engineers do, and unlocking the potential that BIM has as the methodology should extend beyond visual aspects of those applications. A unified library of materials with their real physical properties including embedded energy, carbon content, and thermal conductivity coupled with the ability to quantify building materials in addition to the assemblies, should be top priority if any of these tools want to reclaim their analytical competency.

The conclusion is that when one accounts for all of the complexity associated with the realization of the built environment, we all have the responsibility to critically examine the tools and methodologies that software companies present as “their” best solution and maybe, just maybe this will make them think less about marketing and more about delivering stable and reliable products.

Monday, August 06, 2007

Ameri-CAD Aquired by ITW

Ameri-CAD, the company that has created one of the most comprehensive residential BIM solutions on the market, VisionREZ, has been acuired by ITW. This could be very good news and the validation of ACA as a viable BIM platform. To learn more about VisionREZ check out the following links;
http://www.visionrez.com/
http://www.archidigm.com/Coverpage/cover4-06/lounge-set_vrez_review.htm