Copy Monitor - A Different Way?

Morning musing...

It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.

C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.

Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.

I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.

For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."

Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.

This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.

I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.

New Book - Delivering COBie Using Autodesk Revit

A team of authors led by Bill East (COBie inventor) has finished a book dedicated to COBie and Revit. His team consists of: Shawn O'Keeffe, Richard Kenna and Emma Hooper.

Bill writes:

"This is the first comprehensive COBie How-To Guide! We explain the implications of COBie requirements on your professional standard-of-care. Next, we describe the architectural and engineering design best-practices we adopted to help us capture COBie as part of our standard design process. We show you how to unlock the power of the Revit COBie Extension and Classification Manager Add-Ins to automate COBie file production details. And we show you how to share your new found knowledge with your team, company, and stakeholders."

David Philp, Global BIM Director, AECOM reviewed the book and had this to say:

"This book offers a comprehensive and real-world insight to the COBie value proposition but most importantly it demonstrates HOW this can be practically achieved. This book is an essential read for anyone that is interested in effectively capturing and using project information. If you want to better understand how to deliver COBie from a Revit environment then this book is a must.”

David Light, Autodesk Senior Customer Success Manager also reviewed the book and said this:

"Finally, the AEC industry and the Revit user has an unparalleled guide for helping you understand, as well as deliver COBie from Autodesk Revit!

Delivering COBie should not be scary, as noted, the guidance provided in “Delivering COBie Using Autodesk Revit'” is designed to help AEC industry deliver COBie on any building, as easily as possible.

East and the authoring team provide a detailed history of COBie, so you understand the background of why COBie? It helps demystify some urban myths around COBie, allowing you to better understand the value of this industry standard digital exchange format. The book runs through best practice tips for model development, model configuration and data preparation for Autodesk Revit.

The guide leads the user onto the configuration of the free Classification Manager and the COBie Extension. Lastly, 'Delivering COBie Using Autodesk Revit' teaches the reader how to apply various concepts on a Dormitory Project example, through shared best practice from recognized industry experts, explaining how to prepare the Revit model for repeatable COBie deliverables."

The authors of “Delivering COBie Using Autodesk Revit,” Dr. Bill East, Dr. Shawn O’Keeffe, Richard Kenna, and Emma Hooper look forward to showing you how to make COBie an integral part of the standard design process for yourself and your team, company, and stakeholders. The pre-release spiral-bound “workbook edition” is now available for individual Revit users. The version for purchase by libraries, institutes, and companies available 15-Sep-17.

You can Order your Copy HERE.

Revit 2018 - GEO Reference and Shared Coordinates

I replied to a thread at RFO that asked about Revit 2018 touting support for AutoCAD's GEO Reference feature.

On the surface, there is no obvious difference between how things worked in 2017 (or older versions) compared with 2018. Over the years you may have noticed that the Location Dialog, the one that allows you use a map to locate your project did not do anything at all related to the Shared Coordinate system. All that action did was provide a way for Revit to; originally calculate sun position (and therefore shadows) more believably and more recently to allow for energy analysis estimation to be done.

Now...in Revit 2018, assuming the source DWG file is using AutoCAD's GEO Referencing feature, it is possible for Revit to inherit this data to affect not only the Location (Sun and Energy Analysis) but also the coordinate location of the project (Shared Coordinates).

The thread at RFO also asks about the 20 mile threshold Revit has regarding model size and warning us about model accuracy. The following is a restatement of things I've written in the past. Specifically they asked if there was any change to this in 2018. There isn't that I know of. I included the following to superficially explain the reason it exists.

The 20 mile threshold is a math and computer science problem that Revit developers choose not to lie to us about. They want us to keep the model as close to the file's mathematical origin as possible. External files (and internal modelling) that have data whose extents are larger than 20 miles begin to influence the accuracy of the calculations required to generate and display the model faithfully.

More often than not a civil file is not really larger than 20 miles. It just has elements that are farther away from the origin than that. Revit doesn't mind that issue and it doesn't mind assigning very large coordinates values to the shared coordinate origin (Survey Point).

It only cares when there are elements that are beyond the threshold. For example a file that only has two short line segments that are 30 miles apart will cause a warning. A file with an entire set of contour lines 40 miles away from the origin won't cause an error IF all the contours themselves and other annotation don't cause the extent of elements to also be larger than the 20 mile threshold. Distance from the origin is one aspect and the total extent (X,Y AND Z) of the elements in the file is the other.

Ultimately, the error appears because they want us to know that this external data could negatively affect the accuracy of what we work with inside Revit.

I wrote THIS POST to discuss how I deal with survey files that violate the threshold. It starts out with one issue (transparent elevations/sections) that occurs when the threshold is crossed.

Multi-Discipline Shared Coordinates

In the past I've written that using or invoking Shared Coordinates is not required to keep project files aligned with each other. It only becomes an issue or necessary when each discipline's files are expected to align with models that are produced with software other than Revit and then viewed with other software like Navisworks.

It's my observation that the most common reason for invoking shared coordinates is trying to orient models with the site conditions. Civil and survey data doesn't come from Revit so that practically guarantees that the architectural model will need to deal with shared coordinates. It's only slightly less guaranteed that the other trades have to deal with it.

I briefly dealt with (a short summary) the inter-disciplinary relationship before in the second of these TWO POSTS and it's reasonable advice until the architecture team has to move their model again, relative to the site model. The Master Site and Building Model linked file strategy I prefer becomes tedious when the building has to be relocated; tedious more so for the other trades remaining aligned with the architecture model that is.

The root issue for this tediousness is the Acquire Coordinates tool. Once the trades use it on the architectural linked model any changes to the building location don't propagate to the trade's models well. The position of the architectural model shifts being respectful of the shared coordinate relationship instead of ignoring that and remaining in the same position based on the Project Origin, the way it was linked to begin with.

Coping with this tediousness, we can fix the alignment of models after the building has been moved by taking these steps:

• Remove the architectural link
• Reset shared coordinates
• Link the architectural file again
• Use Acquire Coordinates again

Alternatively the trades can avoid using the Acquire Coordinates tool in the first place. I did write about this in another POST before. It is a long post, and mostly words, so I'll take another run at describing it here with some images too.

The most important thing to do is mark a known location in the architectural model so the trades can adjust the location of their own Survey Point and then use the Specify Coordinates at Point (SCaP) tool. By known I mean, the North/South and East/West coordinates based on the survey data.

When the architecture model is relocated on the site the new Survey Point information needs to be captured to pass along to the team. In the images that follow I've used the same model (Tiny House) I used in the posts I provided links for at the beginning of the third paragraph.

In the following image we see a first pass at the location of Tiny House A. This image is taken from within the Tiny House A model after having used Publish Coordinates on it from within the Master Site model. In Tiny House A I opened the Location Weather and Site dialog to capture the rotation of the model (wrote it down). The coordinates I'm using are based on coordinates defined or determined in the survey by looking at the corner of the property boundary. In this example I made them up so the coordinate values were easy to remember.

Imagine now that the HVAC designer has already linked the architectural model into their own project using positioning option: Auto - Origin to Origin and started working.

The reference plane cross-hairs you can see under the Survey Point in the image that follows are in the architectural model. That's what I used to mark the corner of the survey's property boundary so I'd be able to tell the HVAC designer where that location is. Yes, I linked the Master Site model into the architectural model so I could see that location to mark it.

Earlier while preparing to start work they moved their Survey Point (un-clipped) to the intersection of my reference planes. Then using the coordinate values and rotation information I also sent them they use the SCaP tool to define the shared coordinate relationship it should have relative to site and the building (see following image).

In this case we also need to enter the elevation of 20'-0" because the building has been raised that much in the site model. Keep in mind that we will find that the building and HVAC model both are still at the project elevation of 0'-0". The shared coordinate relationship is where this elevation is defined.

Now we need to imagine that something caused the architecture team to decide the building must be in a different location. The model was moved in the Master Site file and its new location saved when prompted. Now I've opened up the Tiny House model again and I can see where the Tiny House is. I capture the rotation values like I did before. I moved the Survey Point (un-clipped) even though it wasn't necessary. I do need to move the reference planes to mark where the common benchmark is located now.

I've posted the revised building model for the HVAC designer and sent them the new rotation information. The coordinates of the benchmark remain the same...the site hasn't changed after all, just the building's location relative to the site. Using SCaP they enter the new information after moving the Survey Point (un-clipped) to the intersection of the reference planes.

From all three models (architecture, HVAC and site), I've exported NWC files from Revit for use in Navisworks to see how they line up. In the first design iteration they were all on the other side of the site and in this image I can see they (building and HVAC) have moved together to the new location. I've hidden the wall and roof so the duct is visible. The green sub-region is just to mark the property boundary.

If the design requires the building to be moved again, once it has been moved in the Master Site file it is just necessary to repeat the adjustments I've described. This way each discipline's models stay aligned with each other based on using the positioning option: Auto - Origin to Origin.

A summary of the process:

The architecture team is in charge of positioning and they:

1. Create Master Site
2. Link Building
3. Position, orient and elevate the building (or Reposition)
4. Publish Coordinates (or Save Change)
5. Identify a bench mark in the building model (or adjust to mark new location)
6. Capture (record) and then provide coordinates and rotation/bearing information
7. Share model with trades

If the building location has to be changed repeat 3-7 (differences noted with parenthesis).

Trades take the following steps:

1. Link architecture model using Auto - Origin to Origin
2. Place un-clipped Survey Point at agreed upon bench mark
3. Enter Coordinates and Rotation (bearing) using SCaP

When building is moved on site trades repeat steps 2 and the rotation part of step 3. Remember to use/specify Shared Coordinates when exporting from Revit.

It is important to note that ALL of the above is biased for separate firms managing model relationships.

When all the trades work in one firm the Acquire and Publish Coordinates tools work better because all the files belong to us and we have concurrent access to them on our network. This allows us to link trade models to the architecture model and then use Publish Coordinates to pass along the information we have to manually keep in sync using the approach described above.

In the single firm the process and position logic can play out like this:

Files:

• Master Site > Acquire Coordinates from Site/Survey
• Master Site > Publish Coordinates to Architecture Model
• Architecture Model > Publish Coordinates to Trade Models

Positioning:

• Master Site - Survey positioned using Auto - Center to Center
• Master Site - Architecture Model positioned manually
• Architecture Model to Trade Models positioned Auto - Origin to Origin
• Trade Models to Architecture Model positioned Auto - Origin to Origin

Copy Monitor Wall Location Line Selection

I mentioned in a previous post that 2016 quietly introduced a parameter that lets us choose which Location Line is important to reference when we use the Copy part of the Copy/Monitor features.

Now that I've been trying to use it regularly I'm running into a quirky situation since installing R2 (I can't say for certain it doesn't happen in the previous version too). When I select a wall it works on the just the first wall. When I choose additional walls I get this warning.

Initially I thought it was happening because I thought it is important to assign the Location Line of the walls in the source linked file to be the same as intended in the host file, but then I don't remember having to worry about that earlier...pause...

Then it occurred to me that whatever Location Line setting I used for the last wall I sketched, in the host model, might somehow influence the process. I tried that and I don't think that matters at all; and it shouldn't in my opinion.

After experimenting a bit further it only works reliably when I use the Multiple selection option to choose all the walls I want to use Copy/Monitor on. I've repeated this using stock content (Imperial) and Architectural and Structural templates. If you'd like to corroborate my findings please try these steps:

• Start a project with the Architectural template
• Create six walls with: Basic Wall Exterior - EIFS on Mtl. Stud
• Use Location Line: Wall Centerline
• Save the file as Test CM

• Using the Structural template link Test CM
• Create a Stud 2x6 wall type (6" because the stud layer in the linked wall is 6")
• Start Copy/Monitor
• Map the linked wall type to the host's Stud 2x6 wall type (in Options)
• Choose Location Line: Core Face: Exterior (in Options too)
• Start Copy and select one wall (no message)
• Select another wall (Error message yes?)

I suspect the nature of wall joins is affecting whatever method they are using to evaluate the wall for the C/M process.

• Use Undo and Start again before using Copy/Monitor
• Set Options again, just to be sure
• Start Copy
• Select Multiple
• Select all six walls
• Click the little Finish button (no error?)
• Click the big Finish button

Earlier I mentioned being concerned about the Location Line setting of the walls in the linked model. I tested for that by starting with walls in the linked model assigned to Location Line: Core Face: Exterior. It didn't make any difference in my testing (see next image). Fwiw, when I first saw this new option appear I did think that was what they intended us to do but Revit just places our version of the wall according to the chosen Location Line position, not according to what the source wall is actually assigned to.

Thinking about it further I realized that if we really could influence this by changing the value in the linked model it should have already been easy for us to use C/M; if they just allowed us to swap wall types based on their setting. Revit was biased to only use Wall Centerline, ignoring the others.

I was nearly convinced that all I had to do was make sure to select the walls using the Multiple option but then in another file it didn't seem to matter or help regardless. Then I noticed any wall I was successful using C/M on (picking them individually) but was touching a wall that generated the error message also needed to be eliminated so I could start again clean. When I used Multiple after getting back to a clean slate I was able to use Copy/Monitor without an error message.

I conclude that the safest way to ensure Copy/Monitor doesn't generate a confusing warning is to isolate all the walls we want to use C/M on and choose the Multiple option. Remember the little Finish button before using the Big Finish button!

Also remember that anytime C/M gets ornery we can just use Stop Monitoring on the affected elements. Fix the problem elements and then use the Monitor part of C/M to let Revit start watching them again.

Revit Schmevit

Plan, Section and Elevation...the bread and butter of architecture. Why would anyone want to work on these three kinds views of a project and not find that the elements (doors, windows, walls, etc) they present don't match? If I create an enlarged plan shouldn't it match the plan it was generated from, but have greater detail? Shouldn't the windows called out in a plan match those called out in an elevation? Even if you get it perfect at the first submission I guarantee you'll miss stuff when the next design submission is due. By the time you get to the fourth...faahgeddaboudit.

BIM... I don't care if you ever learn what those three letters mean...

PLEASE, in the year of Two Thousand Fifteen, finally abandon your disconnected ways and use Revit (or ...Archicad).

Seriously, because the people that have to read your drawings aren't impressed.

Revit 2016 - Rotate Project North

Technically this isn't a new feature. It’s an improvement of the existing tool. In the past this tool did not faithfully rotate all annotation elements consistently. We’d often find some annotation was either not rotated at all or moved into different positions. They've revisited the code to ensure more consistent results. It’s not a guarantee they've resolved everything since they can only tackle issues that have been identified as problems. We are pretty ingenious at doing things with Revit that the developers didn't imagine. Hopefully we’ll find that it is more reliable when/if we need to use it.

Let me take this opportunity to remind you that Revit’s bias has always been to create a model or building with Project North in mind FIRST. FORGET about the real orientation on site, initially (please). That’s what using Rotate True North is for and Acquiring Coordinates.

Those tools existed long before Rotate Project North. In fact it was only added because people can’t seem to remember to start their project using a Project North orientation. If you’re interested in more of my writing about using Shared Coordinates you can check out my blog post summary.

Acquiring Coordinates between Trades

Revit's shared coordinate features routinely confuse people. I believe I understand them well but I find the various ways people manage to use them can be quite confusing. I've written about this feature quite a bit, enough that I've created a summary of related posts. I was reading a thread at RFO where a user was describing an error message about Shared Sites.

That message appears when a shared coordinate relationship exists between two files and the linked file involved is moved. The thread at RFO hasn't shared a resolution because the person who wrote the original post hasn't replied to my last round of questions. Their claim is that the situation I've described isn't involved. Without more evidence it's hard to say what is causing their situation.

The point of this post is that they also described how they used Shared Coordinates to adjust the position of their work compared to the other team's project file. I've found with some experimentation of my own that it is effective until (IF) the source file alters its own shared coordinate relationship. If that occurs then its necessary to start over, first using the reset technique listed later in this post and then repeating these steps.

Keep in mind, this approach works if you begin modeling your work before you receive a model to use as a reference. Ideally this wouldn't happen but apparently it does. When you do receive another model it's very likely that it won't align with your work. Take these steps to reconcile the misalignment:

• Insert ribbon > Link Revit > select a Revit Model
• Positioning: Auto - Origin to Origin
• Move their model into alignment with ours
• Manage ribbon > Coordinates > Acquire Coordinates - select their linked model
• Delete their linked model (yes, it's counter-intuitive)
• Insert ribbon > Link Revit > select their model again (this time it IS sharing coordinates)
• Positioning: by Shared Coordinates
• Save your work

Our model should now be in sync with theirs until (IF) they alter their shared coordinates. We are using the Shared Coordinates feature to share a common understanding of respective project's shared coordinate origin.

For some background information, Revit projects have a file (reference) origin that does not change, in a way it's like AutoCAD's World Coordinate System (WCS). The shared coordinate concept we are using is similar to using the User Coordinate System (UCS) in AutoCAD to provide an alternate way of seeing the model.

If the team whose model we used to acquire coordinates from revise their shared coordinates in the future we'll have to repeat the process. To do that we'll have to reset the shared coordinates first. We'll also be able to avoid generating the Shared Sites error message above. Revit stores information in our project file about a linked file that it uses to know if a project is sharing coordinates with it or not and we have to break that relationship to reset shared coordinates. This technique uses a separate temporary project file to acquire coordinates from instead. A file can only acquire and share coordinates based on one source file at a time.

We can follow these steps to reset shared coordinates:

• Create a new blank project file
• Put a pair of crossing grids in plan so we can see it when it is linked later.
• Save the project
• Close the project
• Open our model
• Delete the existing linked model (click Remove Link in the warning that appears)
• Insert ribbon > Link Revit > select our temporary new blank project
• Positioning: Auto - Origin to Origin
• Manage ribbon > Coordinates > Acquire Coordinates > select the blank project we imported
• Save our project - it now thinks it is in sync with this new project instead.
• Delete the linked project (Remove Link)
• Save our project - Coordinates are still reset, we can link the real model and acquire coordinates again

Ideally when we link models together we should start with Auto - Origin to Origin because that's all they have as a common reference. Projects usually start with the architect and they establish the coordinate relationship with the site and survey data. Using Auto - Origin to Origin works if at the outset we agree that somebody establishes the site survey relationship and the rest of us all use their model to define our relationship to theirs.

The technique I've describe is using Shared Coordinates to align models instead of using it to align it to the site/survey data. This means that our models will align but exporting to DWG using Shared Coordinates won't necessarily align with the survey data. If this relationship is established after we've aligned our models with this method it is necessary to reset and repeat the process described above to allow our model to acquire the new coordinate relationship.

It's been my observation that Revit's Acquire Coordinates tool does not work well on projects that have VERY large coordinate values (based on survey data). When I write "does not work well" I mean Revit fails to acquire the correct coordinate values. When this occurs I've found that the coordinate values I expected to see were off roughly (less than they should be) by a factor of 10 or 100. In contrast, Revit's Specify Coordinates at Point (SCaP) tool always works when Acquire Coordinates doesn't. It does not define a shared coordinate relationship however. Using SCaP defines what the shared coordinates are at a specific location in the model but it does not store a "relationship" to another file like using Acquire Coordinates does.

I've described one approach to dealing with multi-model multi-discipline sharing of coordinate data HERE. The process described by that post is far more comprehensive and is meant to deal with the entire team. This post is meant to help resolve the relationship between one trade and another. As soon as everyone else gets involved it is important to have one team establish the single source coordinate system to use. A Revit project file can only share a coordinate relationship with one other source file.

Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements

• The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
• The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
• The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
• The Project Base Point will allow us to move our project on the site (relative to survey coordinates) to reposition it (CLIPPED) but the file origin isn't changed
• The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference

Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "survey coordinate system origin" (see image).

That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.

Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.

If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

It is a Training Problem

I frequently get involved in conversations that start with someone wishing Revit would help resolve "x" problem. The essence of "x" is that somebody on the team keeps doing something that the team wishes they wouldn't. So we want Revit to fix a user, or make it impossible for a certain user to do something.

Usually it is just growing pains and those WILL subside after enough time is invested and experience is gained. That's the purpose of training, we can shorten the time required with training. Yes, I do work as a trainer but I'm not just saying that because I'm a trainer (the carpenter thinking every problem needs a hammer). The whole point of hiring a training consultant or going to classes (for anything) is to reduce the time it takes to become productive or knowledgeable.

We SPEND money to SAVE time and invest in our skills.

Too many firms don't invest in their staff (or if they do, they don't do it effectively). They expect or assume that their staff will just manage to get by on their own. Give them a book, they're smart, they'll figure it out. They probably are smart and they will figure it out...eventually. How long can you wait for that to happen? They might pay for training but then after three days in a class they've been trained and therefore are experts! At least that's the perceived expectation or assumption. After all, that's why architecture is such a easy degree to get and getting licensed is a snap, right?

Getting training is a piece of the puzzle. Putting that training to work is how experience is gained. The training makes it possible to shorten the learning curve toward experience. No matter which way you approach the learning don't underestimate the importance of the experience of doing the job, the project. You'll just enjoy the job or project more if you get some good training and spend less time getting frustrated.

If a firm really keeps track of how much time is lost to inefficient task completion and inexperience leading to rework. They'd find out eventually that hiring that consultant or training facility would have been a bargain. If we don't treat "time lost" as "money spent" we don't realize how much it really cost. So many firms behave this way, they don't pay attention to the money going out the door the slow and "invisible" way. It goes out so slowly they convince themselves it isn't happening. If you are serious about seeing a return on investment (ROI) you need to know what it costs to do everything now (the established or "old way") and then later after becoming proficient with Revit. As they say, you can't manage what you don't measure. Keep in mind that lots of data doesn't necessarily mean it is useful.

A senior architect mentoring an intern architect is the same thing, your experience helps the future senior architect become one. You can be a mentor in your office for Revit and bring people up to speed sooner too! So it's not just about hiring a great trainer, it's also about striving for better continuously.

We sprung for training and people are still making mistakes and they've been warned repeatedly!

Mistakes are one thing, we all make them. If people know better but keep doing the same thing over and over again you now know what they really think of you and the firm. They don't care! They don't care enough to "play along", be a "team player" (OMG, holy catch phrase Batman). Sorry but AEC is a team sport.

Messing up other people's work IS a training issue, until it ISN'T anymore.

If people are trained and continue to be RUDE and refuse to work well with others it is no longer a training issue. It's a HR (Human Resources) problem, yeah I mean "possibly cost them their job". A firm (and it's staff) shouldn't have to tolerate people refusing to work together well. That's easy to write, not as easy to work through, I know that. Someone once said to me, "Yeah we have a few people who should work for our competition". So I say, "why aren't they?" (big grin)

Ignoring the problem, yeah how's that working?

Plaaaaay BALL!

Our Model is Clash Free

Offering a "clash free model" is a bit like the car ads on television that offer a 100k car for $299/month. When we read the tiny print we realize that the monthly cost is more like $1600/month and mere mortals won't qualify for the financing terms. Like the car ads, we have to carefully declare/define what a clash is. What sort of clashes are acceptable (and therefore not considered a clash) and those that are not (and therefore are a clash).

One simple example, pipes pass through walls. If they don't cut a hole in every wall at every location where a pipe intersects with a wall then technically we've got a clash. If it is a poured concrete wall that requires a sleeve it is a bigger deal (even bigger deal if precast) than a wood/metal framed wall with gypsum wall board. By the time we are done defining clashes our client and/or team will feel like they are getting "nickel and dimed" to death. ...and that's just for our work...

We can't offer a clash free model if everyone else working on the project isn't working toward that goal themselves. Our model might be "perfect" (according to our fine print) but if they aren't coordinating their work with ours...and vice versa...we'll still have clashes. It's not a one way street.

It is also a moving target as a project moves through design phases. Are we promising "clash free" when people start swinging hammers or is it clash free within two weeks after receiving an architect's model, at the end of each design phase?

"Clash Free" - It's a worthy goal and one every client and project team would love to achieve. It's not possible without considerable commitment by everyone and can't be achieved in a vacuum by one part of the team. In my view someone casually offering "clash free" suggests to me that they may not have enough experience yet. Anyone who has been part of weekly clash review sessions can attest to it not being a trivial matter.

It seems to me that's just the sort of promise that keeps lawyers busy...

Modelling Serendipity - Revisiting an Old Post

In July 2009 I wrote about "Modelling Serendipity" when I encountered something that made me ponder my past work. Some recent conversations made me think of it again so I thought I'd put a link here to point at it again.

I recently told somebody, "I don't know what I don't know and I find that I bump into what I don't know in 3D faster than 2D"...that's modelling serendipity.

A RELATED POST (Sept. 2009), related to the notion of 3D shop drawings.

No Not Detail Lines

Here's a recent situation for a Revit MEP firm. They download the architect's model. They import the model. They need to coordinate their design with a good number of lab cabinets and equipment. When they open the views to see the labs they don't see any equipment. Curious, they open the pdf's they were sent. Casework and equipment galore. Now they open the file that they downloaded and take a closer look. Sure enough, there are cabinets and equipment. Closer look still...oh, no! They aren't families, they are detail lines, drawn in the view. Some are groups, some aren't.

Now we know why they don't show up in the RME model after linking the architectural model in. Detail lines are view specific so they won't show up unless they override the view to show the same view the detail lines are in within the architectural model. Doing so unfortunately introduces other annotation they don't want to see. Nuts and double nuts!

Moral of the story, if using detail lines seems like the expedient thing to do, just ask yourself, "Who does this affect downstream?". Sometimes you just need to say no. If you can draw it once in plan in the project with detail lines you can expend just about the same effort to make simple plan only families and be nicer to those you hope to collaborate with.

I saw this bumper sticker on a Facebook site called PA of the Day.

They post a picture of various Public Address (PA) systems/equipment each day. It's a site that appeals to a certain group of people. A twist on a familiar drinking and driving bumper sticker and for the purpose of this tale, "Friends don't let friends use detail lines instead of families!".

Dept. of Echo - An MEP Coordination Memo

A retweet, using Twitter terminology, Jason is the creator of Revit Garage, a blog for Revit MEP. His post tonight is worthy of echoing in my opinion if it helps get the word out, so to speak. He hasn't posted a lot but isn't just about quantity eh? A couple of cogent points he makes that I'll snip and include here but please read his full post.

snip...
Deleting architectural elements: To the largest extent possible, please modify host elements (walls, floors, roofs, ceilings, etc.) rather than deleting them and replacing them with new elements. Some MEP objects such as light fixtures, diffusers, wall devices, etc. are hosted to these elements. If these elements are deleted, MEP objects can become orphaned and require a considerable amount of time to re-host. If an element must be deleted, please inform the MEP project team member so that appropriate actions can be taken.


snip...
Worksets: It is common practice for Revit MEP users to set their views to “By Host View”. This allows us to easily create and modify views to fit our requirements. Therefore, when creating a workset, please keep in mind that if the “Visible by default in all views” option is not checked, any object placed on that workset will not be visible by default in the views created in the MEP model when the architectural file is linked. Therefore, for such elements to appear in views within the MEP model, the MEP project team member has to take extra steps to create views that are linked to views present in the architectural model.

Modeling Serendipity

In the debate about should we or shouldn't we use Revit (or 3D etc.) people overlook the intangible stuff that is hard to quantify until you encounter it, the title of the post. I'm writing about that "thing" that happens when you create a 3D model of something you "understand". I'm not trying to be insulting because I know that I've created models of things that I thought I understood and then found I didn't fully appreciate the impact it had on other related items later on.

Once upon a time I worked for a theatrical contractor that specializes in stage curtains, rigging and lighting systems. One of the things I did back then was shop drawing for our projects. We were careful to show how our equipment interacted with the building. Yes...these were drawing done by hand on vellum/mylar and with technical pens/pencils. We eventually used AutoCAD too.

All too often a site visit would find sprinklers and their pipes suspended from "our" rigging steel, ducts in the path of travel of curtains and lighting, drains and other sundry items in the way of our other equipment. Not that we didn't try to coordinate this stuff. Things like this need some room!


Usually when I'd talk to a contractor the story was, "Never saw those shop drawings, wish we had! Well, our stuffs in, work around it!!".

This is where I'd get to be "theatrical" and be a "Prima don". In a job trailer full of angry contractors who have just been told that much of their work would need to be redone I calmly explained that the reason the building is getting built is so that the equipment we are supposed to install actually works. If "our" stuff doesn't work then we can save the client a lot of money and stop building the building, won't need it after all.


As you can see in the image above there isn't a lot of real estate available to just put stuff any old place you want in a stage area. Once supplied with the "bigger" picture, sighs all around and a few "who's going to pay for this?" and they worked it out so we could do it right the second time. This happened more than a couple times over eleven years unfortunately.

Fast forward to Revit and modeling buildings...if our submittal was 3D and their submittal was 3D and everyone's was...we could evaluate this coordination much more efficiently than sitting in a job trailer and arguing about who was right. The sad truth is that too often the 2D drawings in the field don't get in the right hands at the right time. There are great projects and teams and then there are others...it takes all kinds.

Serendipity is when you realize that you didn't fully understand something. It comes when a collection of models means a dozen players solve a problem in an hour instead of spending several hours just trying figure out if there IS a problem. Consider that this usually meant flipping sheets and asking questions like, "What's the bottom elevation of the beam again?" "What's the duct size again?" "It says Top of Steel is 28'-0" but the finish floor is "27'-8", what gives?"

There are so many good reasons to do it...even some you haven't considered...yet. Climb down from the "fence"...

Credit is due for the images above:

The first image above is a custom winch assembly to lift a 22,000 lb. media screen at the Newseum in Washington, DC. The winch couldn't be mounted above so it "self-climbs" and had to be built to lift 34,000 lbs instead, its own weight plus the screen. An aside, I dealt with the sale of a similar winch and did the shop drawings for a project in Seoul when I worked for JR Clancy. The winch had to lift a prop, a small car, very very very fast so that it could arrive in the scene during a change and then disappear during a subsequent change. Oh and that's Rod Kaiser, an all around good guy. There is little he hasn't seen or done in his many years with JR Clancy.

The second image above is a capture from a magazine article featuring the Alden Theater in Maclean, Virginia. The magazine is Stage Directions. The article was written by Kathleen Burke and is called Revving Up. The theater contractor/consulting firm, Pook Diemont & Ohl was hired by the awarded contractor/consulting firm Barbizon Capitol. They used the equipment manufactured by my past employer JR Clancy.