A simple way to try out Dynamo on building projects is to use it to extract, compute and move building data. One example that I love to show uses the problem of tagging and scheduling building component elevations in Revit. Last week my buddy Hannes (svensken) at Dark asked about this for Ceilings. I decided to make a short (and fast) video recording of one way to do it:
This example uses an already existing parameter (Height Offset From Level), and adds it’s value to a (manually entered) number. If the objects your are manipulating do not have this parameter, you can extract their geometries, find vertices and their respective Z-coordinates. I believe you also can extract the global elevation automatically from Revit’s Site Location, but that may require Python/API work. The definition produced in the video only works for Ceilings hosted on Level 1. To make it work on multiple Levels, install Andreas Dieckmann’s Clockwork Package, use Element.Level and add the Level Elevations to each Ceiling.
It is a common misconception that Dynamo is a geometry engine for Revit. William Wong at CASE recently wrote about that in his blog post Dynamo: More Than Grasshopper Lite. Dynamo can build advanced, mathematically defined geometry. So can Grasshopper. But Dynamo can also compute building data. And that makes it a unique product.
Using examples like these can be a good way to learn visual programming, test Dynamo on projects and teach your colleagues about data manipulation. Let me know if you come up with other ideas!
Håvard Vasshaug 
Pingback: Using Dynamo to manipulate building data in BIM part 1: Shared Elevation - Revit news
Pingback: Weekly Roundup – 2015.10 | The BIMsider
Håvard-
Great post showing the potential of Dynamo to reduce errors and alleviate the mundane. Dynamo for the regular people. The next step I took when I did this was to push the calculated height to a string so that it can vary across group instances (yes-groups are a pain, but also useful for multistory).
I vote yes to having a non-Dynamo interface available for “consumers” so that they can’t mess up a definition that works. In a perfect world, everyone would be curious and have unlimited time to learn the background stuff. But the reality is most firms will only have a handful of Dynamo producers but a lot more potential consumers, and the more streamlined approach will work much better and produce less “accidents” in the long run for the non-Dynamo staff.
Thanks for your comments Ben. Always nice to hear your thoughts. H
Dynamo should be just like LISP for autocad, load what you need to complete a task. Having tons of add ins I feel would be just confusing.
Great post Havard. We hope to have that units issue fixed soon. So what would you think if we made a way for people to publish tools like this as revit addins or similar so that non-computational designers could use them without even knowing that they are using Dynamo? Would that be bad because they aren’t learning anything about Dynamo or good because they could just get their work done? (or a bit of both ;))?
Thanks Lillian. My initial through is to have people use Dynamo and not bake this as add-ins. People should (and will) learn about what’s going on in the background, at least superficially. But, I would love to see a way of using existing definitions without having to deal with Dynamo and Custom Node versions. That’s when my non-computational designers start to mentally wander. It’s just too much work keeping track of versions.