Copy/Monitor Documentation

The Autodesk BIM User Assistance Team is continuing work to enhance the online help. In this example, they are revising the Copy/Monitor documentation.  Below is a version tailored for Revit Architecture (If you prefer a MEP or Structure version let me know).

_erik

Revit Architecture Copy Monitor Draft

From the User Assistance team:

In response to customer requests, we have enhanced the documentation that describes the Copy/Monitor tool. In addition to conceptual information (Why should I use it? When should I use it? Which elements can I copy/monitor?), this documentation includes workflows, procedures, best practices, and troubleshooting information.
This posting is a PDF generated from the online help file, so it looks like the online help, but the hypertext links are not active in this particular edition. We hope you’ll overlook this minor inconvenience, and focus on whether the information tells you what you need to know about this important feature of Revit.
We look forward to any feedback you can offer.

Comments

[Joel Osburn]

I'm having a hard time coming up with constructive criticism; the fact that this documentation is being created leads me to believe that copy/monitor is still not getting the overhaul it desperately needs in order to be useful.

The posted docs lack any discussion of why Copy/Monitor in its current state might be used. The shortcomings listed are the tip of the iceberg, and give no guidance on how anyone ought to deal with coordinating Revit models that have footings, beams, plumbing fixtures, light fixtures, roofs, and on and on, that need to display and be available for analyses in multiple models. As near as I can figure it, all we can really do is link the models together, and figure it out ourselves. We copy/monitor grids and levels to get notifications, but even with walls, the flakiness of copying various types is a pain. The inability to preserve phase data is often a deal breaker in and of itself.

At the very least, the docs need to expand the description of Copy/Monitor, Coordination Review, and Interference check to not only describe what each of those tools does, but when and why one would use each. Remember all of those requests for workflow information? Here's where it is needed most: putting various people and information types together in a cogent, useful, productive manner. Second, the docs need much more acknowledgment of and work around suggestions for dealing with the plethora of object categories that C/M can't deal with, but that every project using such modest building elements as beams and a roof, will be required to address should they choose to use more than one Revit model.

[Dennis Nelson]

I think it's great that Autodesk is looking for feed back, but I agree 100% why revamp the documentation when that fact is the tools itself needs to revamped. We don't use copy monitor because it's not worth the pain and in some instances just doesn't work. Fix the tool then work on the documentation.

[brad]

Second and third the above comments. Though one of these days I am sure I will have a project made up entirely of vertical columns with no cross bracing, beams, roofs, or any of that other extraneous stuff that makes up most buildings.

Copy monitor was a bad idea to start with; but had it been taken to any logical level of completion it could have still been useful.

[Tom Vollaro]

Point taken about working on the tool. Keep in mind, the UA team is working in tandem with future development. That said, can you guys expand a bit more about why Copy/Monitor is insufficient for your work?

[DoTheBIM]

I'm with Tom. I've heard/read before the copy/monitor is not the greatest tool for real life projects and that it could be a great asset. We don't really have a need to use it at this time, but it would be interesting (for my future reference) to see what people feel works and what doesn't.

[Joel Osburn]

Tom-

I'd be happy to have a conversation about how and why copy/monitor has left us hanging. If you're interested, let me know how you want to get a hold of me.

[Dennis Nelson]

Here is a quick run down of the some of the issues that we encountered. We are a structural engineering firm and we tried to use the copy monitor functions, on a 28 story concrete constructed condo tower. The arch had started the model so we thought it would be a good test. We copy monitored the grids, levels and slabs. We thought it would be nice not to remodel all the slabs since the arch was going to own or control them. I will say that levels and grids worked great. We had serious issues with the slabs though.

1. Since it was early DD every time we got a new model the list of changes was mile long. It took almost a day to go through the list of changes. Which is partly because of the way the dialog box is organized and interacts with the model. It would be nice to have the ability to sort the list with more options. For slabs it would be nice to have them listed by level. This way I could see each slab element that changed on a given floor, and also quickly isolate elements that are close to each other. Also the interaction from the dialog box and the model is clumsy and needs to be improved. If you are going to have a tool like this you need be able to find and isolate elements quickly in the model. You also need the ability to work in the model and without having to close down the dialog box, because when things change you want to see how that change will affect the element surrounding it. I think this is a dialog box that needs to have the ability to dock some where. You should be able to highlight or select elements form the list and quickly isolates those elements in the model. Also the “show element always seems to find the most obscure view that the element is shown in. I think it should search through the views on a sheet first.

2. If the architect deletes a slab and puts a new one in its place. You will get a message that an element was deleted, but you won’t get an message saying that a new element has been put it the model and do you want to copy monitor that element.

3. Point and line slopes didn’t copy monitor slab came in flat in our model even though arch had sloped them.

4. We had some trouble with openings in slabs not getting moved or showing up at all even though they were clearing in different spots in the models. It could have something to due with #2 but I didn’t research it to much because this was the last straw, and decided to scrap the copy monitor and just linked the arch slab into our model.

[Aaron]

A few more thoughts on how CM falls a bit short. Let me preface this by saying i think this is one of the single most IMPORTANT tools in the program, and it can be AMAZING if it works right.

ISSUE 1: "You dont know what you dont know." IE, Im mr ARchitect. I put in 30 grids. You CM them. Tuesday, i add 4 more, and send you an update. "You dont know what you dont know, and neither does CM..."

The combat to that problem is “rule based CM.” I want to tell CM to Copy and Monitor EVERY grid in the project, that exists now- until forever. An exclude tool would be great too. “Exclude” this particular grid from CM, while monitoring every other one. Would it still be a pain if it was deleted and recreated? Sure, but it’s a pain in OVERNOTIFICATION and not UNDERNOTIFICATION. So you’re safe.

Allowing CM to utilize Filters would be amazing too. As Filters in Revit get more rebust, we use them all the time. I could see a Filtered-Rule-Based-CM that goes like this: Engineer says “CM every floor in the project (forever), but Filter OUT selection of Floors with Type Comments *Finish*” and Boom: They don’t get my Ceramic Tiles.

ISSUE 2: The Types in Options. This is insane. If I have to TELL it what Type to make a wall when it COPIES a wall, the process has fallen flat on its face. Now, I agree: You may need to OVERRIDE it, but what it needs to do is this: Provide options.

Option 1: First, it should populate the types with the ones its copying from. It HAS to be able to get them… It can read the instances and type properties already, and I can see the family type definition. Now isn’t the time to get worked up about IP of family content, because they HAVE our model. I want the family types im copying to be IMPORTED in to the poject im copying. THEN, even the parameter values can be copied and monitored. (Small project/big project issue: I don’t know exactly how that works with Shared parameters and the like, but its HUGELY necessary). Think of the power here: I put in some Architectural elements, that (obviously) require electricity. (okay, so this is down the road, but still… entertain me). Through a set of Shapred parameters ive worked out with the engineers, the values THEY need for energy analysis are in MY content. They CM (rule based “take them all”) the equipment, and everything is fantastic. Two weeks later I find out my client needs a way bigger server than they thought, so I double some parameters value in the system. It tells them, and suddenly THEIR energy calcs get updated. Then they get warnings from THEIR systems. Wow, that would be sweet.

1a. Another reason this is important: CM a wall, that has a door that has a nested Light fixture inside it. The OPENING of that DOOR now reaches the full extents of the LIGHT FIXTURE too. This makes the feature fairly difficult and error prone, when you get in to linked models where people use nested families. If I have a door I call “rear exit door” im not going to place a light above each one manually… im going to nest it. Drives my Structural Engineers NUTS.

1b. CM a wall with a different wall type, particularly with complex wall joins and edited sketches. The walls need coordination review right from the get go.

Option 2: Once it has populated the list with all the types FROM the project, THEN give us the option to override. So if structural doesn’t want my EIFS coating, they can manipulate the wall type and remove it.

ISSUE 3: The number of items that need to be CM’able needs to SERIOUSLY increase. Floors, Wall, Grids, Levels, Ceilings!!!, Roofs, Masses, Doors, Windows, Components (just about every category… It really is necessary. But option one above (copy them in to the project) would help with this)

ISSUE 4: As mentioned above, the dialogue is very difficult to work with. I need to be able to work WHILE the dialogue is opened. But furthermore, the OPTIONS need to be reworked… They get confusing for inexperienced users. And it doesn’t need a large study done, its easy:

“An element has moved position”

Accept New Position
Restore Monitored position
Postpone decision.

“An element has been deleted”

Accept Deletion
Restore Item
Pospone Decision

“An item has changed Type” (assuming types could copy)

Accept New Type
Restore to original Type
Postpone decision.

The “Modify” option is very confusing. Does it mean Modify to MIMIC the change, or Modify to put it back? Accept “difference,”… Does that mean accept that theyre NOW different, or accept the difference, and change it? It’s a boggle.

It’s a GOOD tool. It has GREAT potential. And it could be an AMAZING asset. Thanks again for the forum, and for listening. :)

[brad]

I agree with the above, but let me save you a little time (sort of). Forget about CM and focus your attention elsewhere. CM is Pandora's box (see examples above and extend across all building elements which require coordination) and everything wrong with our current system with a little bandaid trying to hold the lid shut. Solve the underlying problem (or in Autodesk's case, enable solutions to the underlying problems) and the need for CM goes away.

The current problem (which CM aims to resolve a little corner of) is multiple versions of the same entities are created. Location 1, the Architects copy of the model which is constantly being revised. Location 2, the copy of the model sent to the structural consultant which is now out of sync. Location 3, the copy sent to the MEP consultant also out of sync. Great so everyone has outdated stuff from everyone else.

Just to recap, we have:
the Architect working on their "true" model with outdated MEP and Structural.

MEP working on their "true" model with outdated Arch and Structural

and Structural working with outdated MEP and Architectural.

Now, let's put them all together daily or more likely a couple times a week and see what happens? It doesn't work is what happens.

How does this save you time? Skip the smack the mole game with CM. There should be one combined model with rights/ownership of elements and data. Now, rather than having the CM tool with all the problems it drags along with it, you are simply left with a Monitor tool. Ah.

One model. One source of "truth".

[Aaron]

Brad-

Its a great premise, and thats even "the hype" that the new Graphisoft article is pushing. But its nothing that a software vendor (in my very humble opinion) is going to be able to resolve.

Unless everyone is under one roof, youre left depending on restrictions of hardware and bandwidth, unless youve got gold lined pockets or an endless supply of time.

I would love to see Structural update everytime i hate SWC, but in the interim i think CM affords us a lot of great checks.

Besides, the moment you look at things like Grids on Drawings, the "One model for all" becomes a tough pill to swallow. In the spirit of UNDERnotification vs OVERnotification, again: In a "one Model for all" scenario, you would still need SOME version or alert system to appraise you of what the other parties are doing. If youre moving grids and im happily detailing away without notification, its like getting the rug pulled out everytime you hit save...

[Anthony Hauck]

I can conceptualize a more generalized feature that works more like a diff engine. Changes are shown with a special graphic in a mode. You could filter on time, category, or discipline criteria. The non graphical changes would be an additional challenge and as always the devil is in the details.

[Joel Osburn]

I think Brad is right, were the world a perfect place. With a real database server hosting the model(s), WAN performance could be such that the one-true-model fantasy is then feasible. A true permissions system could allow filtering views by whoever last modified, or elements created since this morning, or whatever was needed. And even so, tracking objects in the model will always require communication; software can't solve every problem.

I'm not holding by breath, though. A major rework of C/M seems a more likely occurrence, and were it done well, C/M could be useful. Integrating the three applications would certainly be welcome, no matter how you slice it.

[Joel Osburn]

Color coded diffs would be awesome. For use every day, and for coordination meetings, this could really streamline communication.

[brad]

Aaron, one of the main points is that there would be a Monitor tool to notify the appropraite stakeholders when something changes.

It's actually a lot simpler to build out that way (true db server) than to spend the next 10 years trying to work out the bugs of trying to "monitor" 3 or more asynchronous representations of a single entitiy (refer to the issues Joel and Aaron point out, then multiply by all of the stuff that really should be availabe for CM...whoa!). We've done that. It's part of the reason our industry is so unproductive.

Anyways, bringing this back on topic. I would much rather see a database server scnario in 5 years than new CM features in 1. Were it a perfect world I guess (hah hah), you could do both...I'm just voicing my opinion of priorities.

[Aaron]

Im not disagreeing with you, really. "Were it a perfect world" i think id rather see them focus their energy on your way too.

But its not perfect, and CM is something thats useful in THIS world.

There are so many facets of the "One model truth," that even if it existed tomorrow, im not sure it would hack it in the real world.

In that regard, if its have the Factory spend five years on something that may or may not be useful, or spend a year or two on something thats already useful and could be even better (especially considering some sort of Monitor has to exist in the perfect scenario as well), then im voting to have CM worked on.

But wow, getting it REALLY back on topic:

The color coded thing would be GREAT!!! I draw a Grid. Structural CM's the grid. I move the grid. He reloads my model. His grid turns RED, my Grid turns GREEN. (So hes seeing both). He goes in to Coordination review and thats where it asks him to approve or deny. That would be neat.