Friday, 27 December 2013

Read Your Warning Messages

Here is a classic example of what happens when you try to do something in Revit that you shouldn’t and end of up causing the rest of your team to not trust you working in the same model. I will start with the first warning message, the steps we took to resolve the issue and end with the first action that started the domino effect.

This was the first warning message that was ignored after a user changed a parameter to a level
(Hint: they were in section) I will tell you what parameter they changed at the end.
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:

1.       Are all rooms not enclosed or just a few?

a.      This could be a result of a few walls “Room Bounding” properties unchecked
       (Not the case here)

b.     It could a linked model if the rooms are unbound at the perimeter. A linked model has a type property to make it a room bounding object, like a wall instance property previously mentioned.
      (Not the case here)

2.       We check another floor. Is this happening on another floor?

a.       If you are having issues with multiple floors it might be that all the rooms have been modified. Check the base offset, limit offset and upper limit values.
             Turns out the rooms have not changed, all the settings are good and the rooms should be fine.

3.       Third check, and this is the tricky one. What are the properties of the level where the rooms are hosted?

a.       Check the Computation Height
b.     When the Computation Height overlaps another floor with rooms you will get this warning message. Do not ignore this warning.

c.      When the Computation Height overlaps bounding objects (like walls that are room bounding) you get this message:

Basically, the computation height relates to room bounding objects that are hosted to that level.
So, how did this happen? How did the Computation height at that level change to 100’ above the level? In section, a user wanted the level to show the sea level elevation (Survey Point elevation), rather than the project level (Project Base Point). They were unaware of the type property Elevation Base that lets you show a Project Base Point or a Survey Point. Having a second Level family showing a Survey Point would have resulted in an elevation showing the true sea level elevation. Instead, they changed the Computation Height. They got the warning message “Room is not in a properly enclosed region” and did nothing. The elevation number in the level did not change and they moved on.
We often tell users that they can ignore many warning messages, like overlapping room separations lines, and objects slightly off axis. This is really a bad practise since all warning messages are really warning you that you might (most likely are) doing something wrong. Many warning messages are precursors to model performance issues or worse; corruption of the model.
Do your team a favour and make a New Year’s resolution that you will start reading warning messages – and share your warning messages with your team.
Changing the Computation Height back to a range within the floor levels that the rooms were located fixed the issues of the room enclosure and everything was back to normal. Crises averted and a great lesson learned for the team.

If you don’t know, ask…don’t be silent and ignore warning messages.

Happy Holidays and Happy New Year from the HOK buildingSMART Crew.

Friday, 20 December 2013

New Features for Revit 2014

As we begin to implement the latest version of Revit, we have created an online compilation of videos that highlight the key new and enhanced features in Revit 2014. HOK team members can also find a brief PDF handout on the BIM RESOURCES page. Click the image below to access the Prezi.


Thursday, 19 December 2013

Seeking a BIM Specialist for MEP

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.


Friday, 13 December 2013

Recessed Lights in Ceiling Grids

When placing recessed lights into a Revit ceiling (which may be in either the linked or in your host model) special attention should be paid to the relationship of the lighting family to the bottom face of the ceiling:

By simply shifting the geometry in the family down (even a slight amount), the ceiling grid is masked correctly (you'll need a masking region somewhere in the generic annotation symbol or plan view symbol) of the light family:

Thursday, 21 November 2013

Copy/Monitor & Batch Copy for MEP Update

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.Cannot HostI 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.

Face-Hosted family

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.

Final thoughts

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:

  1. Use face-based families whenever possible and name hosted fixtures clearly so they can be recognized and substituted;
  2. Use the batch-copy feature and specify the type mapping so hosted fixtures can be substituted with pre-loaded face-based fixtures;
  3. If you are not going to monitor fixtures for changes in location, do not use the dedicated Stop Monitoring tool. Instead, remove the link and re-link again when needed. This way copied fixtures can be moved around freely without the need to re-host them.

Wednesday, 20 November 2013

Copy/Monitor & Batch Copy for MEP

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.

Stop Monitoring

Unfortunately when you stop monitoring by using the dedicated tool, MEP categories become pretty much useless as they can no longer be modified!

Cannot moveNo Host

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.

Coordination Settings

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.

Friday, 27 September 2013

We're Hiring!

Are you a BIM expert with great leadership skills? The HOK buildingSMART Team has two openings available for a regional buildingSMART (BIM) Manager. One opening is for our Asia Pacific offices, with lead office in Hong Kong. The other opening is for our beautiful St. Louis, Missouri office.

Click either link below for the details and to apply online:

Tuesday, 17 September 2013

Phantom Keynotes

We have had several users report that some items in Keynote Legends could not be tracked down in any sheet view, even after verifying that keynoting default settings are correct. This issue had me scratching my head for a while until I figured out what was going on.
Here’s a typical scenario where this could occur: You have a core & shell project that was documented and under construction and the model gets copied as a new project for the Tenant build-out phase. As the model cleanup process commences, users start reporting that they cannot find some keynotes that are being reported on the legend.
While troubleshooting, I noticed that when enabling the view's underlay, the phantom keynotes showed up together with the tagged elements, which then led me to tweak the view range and ultimately discover how these project files were started and what the root of the problem was: when the view range was adjusted, keynoted elements were no longer visible, but still reported in the Keynote Legend. As you can see in the image below, a plumbing fixture was keynoted and properly listed in the legend:
Keynotes OkIn another view, the cut plane and top plane were lowered until the element and keynote were no longer visible in the view::
Keynotes NOT Ok
In the above image, you can also observe that right-clicking the family type also reveals that the object is not visible in the view, yet it reports in the legend. Note that hiding the element and/or tag in the view makes the legend update accordingly, but in the above example the legend is misreporting.
This has been confirmed as a bug and slated for a future fix. In the meantime, please be careful and use this example to help in your troubleshooting efforts.

Monday, 9 September 2013

Cut Representation of Slanted Columns

We have confirmed a bug with the cut representation of sloped Structural Columns in views set to a Coarse Detail Level (EDIT: the bug seems tied to the symbolic linework that shows only in Coarse). This issue occurs in Revit 2014 SP1 and in prior versions as well.
The Structural Column family in the following example was set to not show pre-cut in plan views. When the Detail Level of plan views is set to Coarse, the cut representation is inaccurate. In this example, the slanted column (End Point Driven) was modeled in an elevation view from Level 1 to Level 5 and later stretched past these extents. A view associated with Level 1 (Fig. 1) was modified to have the same cut plane location and bottom plane as another view associated with Level 4 (Fig. 2). We expect the cut representation to be unaffected by the view’s Detail Level, however as you can see the column cut representation is incorrect when this is set to Coarse:
Fig. 1
Fig. 1

Fig. 2
Fig. 2
Also slanted columns, stairs and probably other categories, are not respecting the view’s Depth Clipping settings and are shown in full projection below the cut plane. Until this bug is resolved, please use caution and avoid setting your plan views to Coarse Detail Level when locating interior objects and equipment around slanted columns.

Tuesday, 27 August 2013

Revit 2014 Performance Technical Note

Do you need some guidance on real hardware requirements for Revit and tips to keeping your models performing as smoothly as possible? Autodesk has released their latest Model Performance Technical Note for Revit 2014.

In this white paper you will find detailed recommendations for hardware at three levels of performance in addition to requirements for using Revit Server. It also includes model optimization tips and best practices for Architecture, Structure, and MEP.

Download the guide from the Autodesk white papers web page.

Wednesday, 26 June 2013

Positioning of Linked Models – Part 1

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.

Fact #1

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.

Startup LocationTo 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.

Fact #2

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!

Fact #3

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:

Coordinates not Shared

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.

Friday, 7 June 2013

Opening Linked Models for Editing

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.

Open and Unload

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:

  • Revit should be capable of opening non-workshared links directly and leave them loaded in the aggregated (host) model.
  • If the link is workshared, Revit should recognize this and serve a UI that offers the same options when selecting a workshared file in the Open dialog so we can 1) open a detached copy, 2) create and open a local file so we can make changes and sync them with central (default), and 3) offer the option to open the central file directly.
  • Give users the ability to edit a link in-context (in-place), whether it is workshared or not. This is not necessary functionality, but would be very nice to have.

Friday, 17 May 2013

LOD Specification is Here!

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.

Cam_LOD200-100 Cam_LOD200 Cam_LOD300

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 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”).

Wednesday, 1 May 2013

Gross Floor Area of a Mass

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.

Monday, 22 April 2013

Wire End Woes

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.


The Fix

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:

Happy Circuit

Happy circuiting!

Sunday, 21 April 2013

Bloated Revit central files

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:

  1. Opened a detached copy of the original project and deleted all rooms. The file was saved as a new central, no purging (155MB);
  2. Opened a detached copy of the original project and deleted all model elements, links, families, sheets and views, leaving just placed rooms. The file was saved as a new central, no purging (108MB). Note that deleting model elements is easier to accomplish by going through the Family tree in the project browser. Since Revit does not let you delete the last type of a system family, you need to create a duplicate of the family and then delete the original one. This ensures that if any elements exist in the project with that type, that they are deleted. Sheets and views are easily deleted through a sheet schedule and view list respectively, both set to not itemize every instance. This allows you to pick the single displayed row and delete them all at once;
  3. Opened the central file created in step 1, created workset “Rooms” and set as Active;
  4. Linked the file created in step 2, Auto – Origin to Origin;
  5. Selected the link and bound it, turning it into a group (did not select levels and grids to be inserted). When prompted, removed the original link as no instances were now placed;
  6. Selected the resulting group and ungrouped it. All rooms were now placed exactly in their original location, with the exception that their workset was now “Rooms”.
  7. The new central file was saved (255MB) and those 200MB were finally released. By purging, this file should ultimately end up as a 170MB project, which is much more reasonable.

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.

Friday, 22 February 2013

Grids Don't Phase Me

We are dealing with a project that has an existing building, demo, and new construction requirements. There is a need to control the visibility of existing grids, grids that will be removed during the demo phase, and new grids.

There are a major limitations to grids that everyone should be aware of. You cannot control the grids by phase; therefore you cannot demo a grid or use phase filters to show/not show specific grids.

In a post by Steve Stafford from 2008 in the Augi Forums it was suggested that you can use worksets, design options, or Scope Boxes to control the visibility of grids. Thanks for highlighting this 5 years ago Steve! And this is still true today.

If your project is not workset enabled you are down to two options, scope boxes and design options.

I looked to explore this in greater detail. I found another limitation, that is related to a new “feature” in 2013. Grids that are created as multi segmented cannot be assigned to scope boxes (#FAIL). So if you have any grids that are multi segmented you will not be able to use scope boxes and your only options would be design options or worksets.

So, how do you use scope boxes to control grids?
1.       Draw your grids
2.       Draw your scope boxes
3.       Name your scope boxes
4.       Assign your grids to the scope boxes
5.       Set the visibility of your scope boxes per view (Overwrite to Invisible the ones you do not want to see)
In this example we start with an existing wall, a few columns and grids all on the existing phase.
(and in this example you will see that Grid 2 and B are multi segmented and will not work)
We then created a scope box.
The Scope Box is called “DEMO
The next step is assign a scope box to each grid.
Grids 1 and A will not be assigned a Scope Box. It will show as None.
We do this so the those grids will always show up. We are not touching them.
Grid 2 and B cannot be assigned since these are Multi-segmented Grids - ask Autodesk why?
Grid 3 and C to be assigned to the DEMO scope box we created earlier.
Now we can demo a few columns (I set the visibility overwrite to RED so you easily see what is being demolished) I also changed the Phase Filter to show the Previous Phase (Existing) and Demo.
Now the new grids need to be added. I added NEW 2, NEW 3, NEW B, and NEW C. Created a new scope box called NEW. I then assigned these new grids to this new scope box. I also added a few columns to the new grid intersections. I quick feature to do this is select the All Grids feature first, then select the grids - the columns will drop at the intersections of the grids.
Notice that you do not see two scope boxes in my views.  That is because these scope boxes have specific views set to show or hide based on the Views Visible Settings.
When you have a scope box highlighted you can control the views via the Views Visible “Edit…” button.
In this case I selected the NEW scope box and used the settings below – I do not want the NEW scope box or the grids related to it to show in the EXISTING or DEMO views.

The DEMO scope box is set to show everywhere except the NEW view
In conclusion, using scope boxes to control your grids is a great method, but until Autodesk change the ability to control multi segmented grids you might need another option like design options or worksets.
If you would like to download this model to explore further, use this link.
Good luck out there and don't let grids phase you. :)