A few days later another user notices all the rooms were no longer enclosed. Looked like this:
So the here are the steps the team took to find out why the rooms were not enclosed anymore:
HOK is hiring again! Among many other great openings, we are seeking a buildingSMART (BIM) Specialist for MEP Engineering. The opening is available for either our San Francisco or Houston office in the United States.
Click here to view the details of the opening and to apply online.
In the previous post, I made a partially correct statement and want to elaborate more on it. I said that re-hosting doesn’t work, but turns out it just failed in my particular test files due to some special circumstances. In general it should work.
When re-hosting fails
In the test files, ceiling-based fixtures were used. When this model was linked and I ran Copy/Monitor, Revit took that ceiling-based fixture and modified it without my knowledge (no warning was ever issued). The copied fixture was not the same version as the original one and it turned into a pseudo-version of a face-based family that is different than a true face-based family: Geometry was on the bottom of the face rather than the top, and there were “remnants” of the original ceiling-hosted fixture, such as a “Ceiling” reference plane. When I tried re-hosting the pseudo face-based fixture, Revit complained and wouldn’t do it.I suspect that the above is due to the trick that Revit is trying to play. Here is the original fixture:
The following is the modified copy/monitored fixture. There is a perfectly valid reason Revit did this, because in the host model there is no ceiling geometry:
However a true face-based family would be like the following image. Note how geometry is built on the top face and there is no “Ceiling” reference plane. I think this is the reason that Revit is unable to re-host the family shown above.
When re-hosting works
When copy/monitored fixtures are face-based from the start, Revit does not need to do modifications on the fly as described above. In this case, re-hosting works as expected. So if you are faced with copy/monitoring of hosted fixtures other than face-based, such as ceiling or wall-hosted, make sure to use the type-mapping feature, so hosted fixtures are substituted with pre-loaded face-based families.
There is definite room for improvement in linked model workflows, especially for the MEP disciplines. The recommendations for transferring light fixtures from a design model to the final documentation model are as follows:
The Copy/Monitor tools tend to be a Love/Hate relationship in that very order. In fact we have recently been using the batch copy functionality because we sincerely love it due to its flexibility. But that love is fading quickly due to some unexpected repercussions.
A common scenario to employ this tool on, has been when a Lighting consultant/designer is working in a separate model (for design purposes only, not for documentation) and our Electrical Engineers need to circuit these lighting fixtures and document them in their power and equipment drawings. These fixtures need to be hosted in the electrical model for proper circuiting. Copying and pasting fixtures one by one from the linked lighting model is highly inefficient. Opening the source model to copy and paste into the documentation model also doesn’t work due to hosting issues (most of these families are face-based and cannot be pasted) and also due to the fact that Paste >> Aligned to Same Place uses the Internal Coordinates to determine location and this is not always consistent between models. On a side note, best practice dictates that you link other discipline models via Auto – Origin to Origin to avoid these problems.
We have received several reports and anecdotes of performance degradation when copy/monitored fixture counts are high, so we have been disabling monitoring soon after the copying is complete and resume with manual coordination from that point on.
Unfortunately when you stop monitoring by using the dedicated tool, MEP categories become pretty much useless as they can no longer be modified!
EDIT: Refer to this post. If you try re-hosting, you have to use the workplane positioning option, which is not desirable. I am not sure why Revit even asks you to do this because copy/monitored elements do not have a host in their properties.
There seems to be no work-around, short of deleting all fixtures and starting over, which is really bad. Lesson learned: Do not stop monitoring with the dedicated tool! If you want to stop monitoring, remove the link. Once you do this, none of the MEP categories will behave as shown above and you can freely move them around and re-monitor at will. These categories then pretty much start behaving as Levels, Grids, Columns, Walls and Floors, which we can stop monitoring at any point without experiencing the same repercussions.
At least we now have a plausible workflow for future projects and the love for the batch-copy tool has been (cautiously) restored.
The nice thing is that you can specify type mapping and only batch-copy one fixture type at a time. Just make sure that if you want to use this as a pure copy tool with no monitoring, to then remove the link soon after. You can re-link it back in, but this is currently the only safe way to stop monitoring without putting future revisions to the position of these fixtures in jeopardy. Autodesk has recorded this behavior but there is no estimate when this will be addressed.
Much has been said about this topic and it continues to be a source of confusion for users of all levels.
When linking models, unless Shared Coordinates have been properly set up between them all, you cannot position them using this method. It seems to be a common myth that linking models by shared coordinates will “just work” and they will land where expected. Think about it: if you never told Revit how various models relate to each other (distance and rotation), how is the software supposed to just know?
First off, let’s get the terminology straight and lay out some facts.
Every CAD software uses Cartesian Coordinates to locate objects in digital space. You start with a fixed Origin (0,0,0) and three Axes (X,Y & Z). In traditional 2D CAD packages, the Origin and Axes are exposed to the user through visual means, whilst in Revit they are not as “in your face”, but make no mistake: they are still there! This fixed system is essential to position elements in space such as points, lines, planes, surfaces and solids.
To find the fixed Origin in a Revit project, you can either use the older, harder way (link a CAD file that contains some linework drawn at 0,0,0 with Auto – Origin to Origin) or the easier, newer way: Use an unclipped Project Base Point and pick Move to Startup Location in the right-click context menu.
Just in case you forgot how to turn this on, see the image on the left (V/G dialog; make sure at least Architecture is selected in the filter list).
NOTE: In AutoCad, the fixed Origin and Axes are called the World Coordinate System. In Revit we refer to them as the Project Internal Coordinate System.
When you link with the Auto – Origin to Origin option, the Project Internal Coordinate System of the linked models will be aligned to that of the host model. So if at project startup reference models were linked haphazardly (ex: with Auto – Center to Center or arbitrarily shifted around after linking), you are guaranteed to end up with incorrectly positioned models. To circumvent this problem, we can set up Shared Coordinates in each model, share them through “acquiring” or “publishing” tools, and then link with this option. Note that a successful outcome doesn’t happen auto-magically on its own!
In most CAD software, you will find the concept of a User Coordinate System (UCS), which is another Cartesian Coordinate System similar to the World Coordinate System (WCS). A user can define any number of named UCSs and these are positioned in space relative to the WCS. Now you can probably understand why the WCS is fixed since you must have an anchor point in 3D space for relative positioning to work.
When we talk about Shared Coordinates in Revit, we are talking about their equivalent counterpart in 2D CAD: User Coordinate systems. We can define multiple named systems in the Site tab of the Location Weather and Site dialog. Named Shared Coordinate systems (Sites) are located relative to the Project Internal Coordinate System. In Plan views, Project North is defined by the Y-axis of the Project Internal Coordinate System, while True North is defined by the Y-axis of the Shared Coordinate System (the named “Site” per the dialog below):
When you link with the Auto – By Shared Coordinates option, the Shared Coordinate system of the linked models (for the current named “Site”) will be aligned to the Shared Coordinate system of the current named “Site” in the host model, given that Shared Coordinates have been properly set up between models. If you try to link models that have yet to be synchronized (by publishing or acquiring Shared Coordinates), Revit will not allow you to use this option:
Revit has always strived to describe functionality using terms that are familiar to the building industry, but I think that the ones used while manipulating coordinate systems do not work well for most common model linking scenarios. Since terminology is so different from that used in generic CAD programs, it makes things harder to visualize and understand sometimes, especially for users that started in 2D CAD. The main problem with named UCSs in Revit being called “Sites” is that if a consultant is linking parts of a building to parts of the same or another building, they probably do not think of “Sites” for this exercise!
The primary reason for the current implementation is to give us the ability to place multiple instances of the same building around a site (ex: the same home floor plan peppered around a housing development). For most typical project workflows, we just need one “site” definition for the purpose of locating links in 3D space and usually don’t even bother changing the stock site name “Internal” to something else.
In Part 2 of this post, we will look in more detail at some of the most common linking scenarios and discuss strategies to set up Shared Coordinates and linking Best Practices.
One of Revit’s annoyances is the inability to open a linked model for editing and keeping it loaded in the host project, all at the same time. This leads users to believe they need additional sessions of Revit in order to refer to the fully aggregated model and edit the link/s at the same. Doing so causes various problems, such as reducing available RAM consumed by the additional sessions (0.35 to 0.4GB/session observed) and the potential to run out of network licenses for other users.
Revit’s UI gives us the option to open a link but at the same time, forces us to unload it. Somehow Revit seems incapable of having the same file in memory (based on filename) both as a link and opened independently in the same session. To make matters worse, most of our linked models are workshared, so opening a link in the way shown above is highly discouraged as you would be directly opening the central file. Revit does have safeguards for situations like this and does not let you directly do a Sync with Central if another user has synced since you opened the central file. Regardless, the current workflow of dealing with linked models is highly problematic and not sufficiently well-developed by the Factory.
Luckily we can work around the current limitations when the linked files needed for editing are workshared. We can in fact achieve this in the same session without unloading or requiring the user to open a separate Revit session by following these simple steps:
1. Make sure to not use the right-click option shown above (obviously!)
2. Navigate to the original linked central file and open through Revit’s Open dialog in the same session. If it is a valid Central File, Revit will automatically create a Local File by appending your username to it and happily open it for editing.
3. Alternatively, use the Revit Launcher (an HOK custom tool) to create a Local File for the linked model in question and open as usual.
NOTE: If the link to be edited is not workshared, you are out of luck and need to open it in a separate session if it is important to you to keep it loaded in the aggregated model.
There is no doubt that this functionality needs to be polished further. The current implementation might be a reflection of various technical reasons/limitations, but should not be a reason to leave things in their current state. Here are some thoughts:
After two years of dedication and hard work, the first draft of the BIM Level of Development (LOD) Specification is finally available for public comment. The work group responsible for this important document is a joint task force consisting of members of the AIA and the AGC of America’s BIMForum.
You might be asking, ‘what is an LOD Specification and why do I need one?’ The AIA’s digital practice documents defines 5 fundamental levels of model development, but offers only general definitions of what each level means. I offered some explanation of these in an older blog post.
This new document offers more detailed definitions of how model authors must create virtual components in order to satisfy the requisite reliability. Building upon the AIA’s original LOD definitions, the LOD Specification can be seen as a companion document – much the same way as a dictionary can be a companion to both an author and a reader.
The public comment period will be completed by early June 2013, but the work group will continue to revise the LOD Specification and publish it on an annual basis. Go to bimforum.org/lod to download your free copy today. You can also read a very detailed article about it by work group chair Jim Bedrick on the AECBytes website (“Level of Development Specification for BIM Processes”).
We had a good Revit question come in from our Dubai office this morning concerning the calculation of gross floor area in a mass. What could cause a mass object to not list any gross floor area in the Properties palette?
First, you must ensure that at least one Mass Floor is selected. You can access this setting by selecting a mass element and then clicking on Mass Floors in the contextual tab of the ribbon.
In this case, one level was selected – but the level was NOT intersecting the actual mass element.
This is a bit of a limitation if you are using Revit for urban design or master planning on a hilly site. You will need to create at least one level for each plateau of buildings in order to utilize the Gross Floor Area property.
If you have never seen this issue before and are an electrical discipline user, you are extremely lucky. When adding wiring to electrical or lighting fixtures built in a face-hosted template, sometimes wires jump around in a frenzy every time a fixture is moved. This is obviously unacceptable, but luckily there is a fix. Let’s break it all down.
You place fixtures, add wiring and all is well. Then you make a change and move some fixtures (because that’s what designers want), and the wire ends are sent off flying all over the place. You think about hurting someone, but keep your cool instead.
So what causes this? Thanks to a tip from Autodesk Support and further digging, it turns out that there is a potential bug in the face-based Generic Model template, which is probably the one used for your families. When the internal origin of the family is in a different location than the ref. planes that define the family origin, you see the above behavior, where wire connectors jump to the “projected” location of the electrical connector.
Below we can see two instances of the Lighting Fixture above with a wire added between them. The wire end connections match up with those of the fixture, but the wire end graphics are goofy.
When the fixture is moved, the wire connects to this “projected” connector location and thus appears to disconnect and jump around.
To fix the problem, make sure the origin defined by the intersection of two ref. planes is at the exact same location as the family’s internal origin. This way the true connector location is used to connect the wire end instead. The positioning of family geometry in relation to the origin is not important for this to work properly. Here is the proof:
A couple of weeks ago I was asked to take a look at a project that the team simply couldn’t open up. The file wasn’t giving any errors and the progress bar sat there at 99% and would not finish opening. To put things in context, this was an FF&E hospital project with about 12 floors and contained links to various other files that housed the building core & shell geometry.
Right off the bat I noticed the excessive file size (about 595MB). By closing the worksets that contained other linked Revit models (about 11 of them), the project finally opened. File size is typically one of the first things to look at when faced with projects that won’t open. In some cases the issue can be easily rectified through a purge of unused elements and a compaction during a sync with central, typically resulting in a reduction of 30% to 50%. Sometimes users fail to realize that if bloated files exist across the board in their project and they load these files as links, they can easily suffer serious performance issues as they run low (or out of) RAM. This is one of the most avoidable problems that BIM Coordinators should watch out for on their projects and can be easily prevented through regular file maintenance.
However in this instance, a purge and compaction only resulted in trimming about 90MB off the file (not bad, but not enough). So it was time for a much more in-depth analysis of the file contents.
My first suspicion was that the project might have contained imported CAD files. A quick search with Ideate Explorer did not reveal any so then I started looking at groups of elements with large quantities. A good troubleshooting strategy is to delete these large group of elements, save a new file (as a new Central) and see how much space is recovered. I took out all furniture families (about 16,000 instances) but the file barely lost 40MB. The families in question were very lightweight and contained mostly plan symbolic representations, which was a smart move for this project’s purpose.
Next I noticed there were almost 7,000 rooms, but did not suspect these would be the source of the problem. After all, they just contain some data, right? Well, it turns out rooms were to blame for this bloated file but I couldn’t figure out how to get this excess amount of bits and bytes released.
After filing a Support Request with Autodesk, I did some more testing based on their recommendations and saved a series of files after deleting rooms by floor (about 8) to try and identify if rooms on a certain floor were consuming more file space than others. Averages revealed that rooms on some floors were using a bit less (ex: 20KB/room) when compared to others (65KB - 83KB/room). However this analysis still led to nowhere and I did not receive further suggestions. Usually Autodesk is eager to take a look at the project file itself but this was not the case this time, even though the SR was filed as Urgent. We were running out of time, so it was time for some drastic measures.
After a purge and deletion of all rooms, the file went down to a very reasonable 65MB. That gave me a goal to work towards. Rooms were consuming about 300MB and if placed rooms were copied and pasted into a new project, they resulted in a 100MB file, which is about 17KB/room. Deleting 800 unplaced rooms from a room schedule did save 23MB, but somehow, about 200MB of space was being held hostage by the remaining 6,160 placed rooms.
Here are the steps taken to fix the file:
You might not be faced with this exact same problem on any of your projects, but I hope it outlines the systematic approach to troubleshooting and resolving issues with bloated files.