It's been a wild ride. Now it's time to get back in business.

Working at CASE was an amazing experience. The collection of talent they brought together was unlike anything I’ve ever seen—truly next-level thinkers, builders, and innovators. I’ve always liked to drink from the fountain of knowledge, but that team was a fire hose. I’m grateful for every bit of guidance, inspiration, and camaraderie they offered.

Then came the buyout. One of CASE’s clients decided they wanted all that talent under their roof, and in many ways it made sense. But three years later, that once-in-a-lifetime team is now scattered to the four corners. I wish I could say we’ve all stayed tightly connected, but like so many things, the day-to-day hustle and distance took their toll.

In the decade since, I’ve been working as a Technology Manager for Consulting Engineers, supporting multidisciplinary teams, developing digital tools, and helping firms bridge the gap between design intent and practical implementation. It’s been a rewarding stretch—hands-on, fast-moving, and a front-row seat to how tech reshapes AEC workflows.

Now I’m circling back to some old interests. After far too long away from writing, it’s time to start again. I have a lot in the pipeline—thoughts, tools, and experiments I’m finally ready to share. I’m also deep into a new Revit Add-In that I’ll be unveiling soon.

If you’ve stuck around this long, thanks for being here. More to come.

Room Separation Lines Don't Play Well with Others

Please Use Sparingly

Room Separation lines are a necessary eval from an MEP perspective. There are times they must be used, and from an architectural perspective are completely appropriate.  Here is the rub, they don't just divide rooms, they also divide spaces. Spaces are used by MEP in place of rooms as they have more parameters pertinent to those trades.  The information derived from calculations performed either in Revit, or more commonly in external applications is stored in these space parameters. Now you may think if it should be two separate rooms, then we should treat them as two separate spaces right? Not necessarily.

The reading space above is separated from the lounge, stacks, and check-out spaces by room separation lines.  Unfortunately light from the windows in check-out and lounge will contribute to the lighting levels in reading.  Air being supplied to the stacks will flow into the reading space. But with room separation lines, there is no way to account for it.

When we are performing calculations for either lighting or HVAC, the two spaces communicate openly. The reason a room separation line was used in the first place is there is no physical separation. Light from one room will cross the imaginary separation line and impact the calculation for the adjacent room. The same is true for air and heat on the HVAC side.

Solutions for the MEP engineer are to use Zones as your export for analysis, which has other benefits as well. But if the doesn't make sense for the two spaces to be part of the same zone, then things get more complicated. There is no way from the MEP model to not have a room separation line from separating the spaces.  They must be deleted from the architectural model.  Then fake tags must be used to distinguish the two room tags from the architectural model, and they must be managed in the MEP model as well. Or the two rooms can be merged in most of the outside calculation platforms. If you are choosing to manage it outside Revit, you will have to be careful when updating to re-merge the spaces in your external software, and you will need to pick which of the original two spaces will be the container for the information.

Model It Right!

Another problem we see all too often with room separation lines is as a band-aid for poor model craft. Perhaps a room doesn't close properly due to an opening or non room bounding element that isn't obvious.  A room separation line is a quick way to fix the problem.  Unfortunately that gets translated in the calculation software as a wall opening. Assuming the line is drawn along the length of the exterior wall, then the room is seen as not having any surface separating it from the outside. To be brief, lots of calculations are reported wrong. 

Revit File Sizes

Revit’s approach of an all encompassing file can create some behemoth sized files.  How big you might ask, very big.  The file size you see on the disk is a compressed file format.  When that file is opened in active memory, the RAM used is about 20 times the file size.  You can check that using Windows Task Manager.  From the first submission (typically Design Development or DD’s) to 100% Construction Documents (CD’s) expect a growth factor of about 3 times the DD file size.  Let’s put some numbers on this… my office is currently working on a large project, about 300,000 Sqft.  The architectural and structural files that are each linked into the project represent the MEP model’s memory overhead.  Together these two files are measuring about 200 Megs.  Well, 200 Megs X 20 = 4 gigs of ram in use.  Then there are the MEP models that currently about 160 Megs x 20 = 3.2 gigs.  We are currently at our first submission, and are totaling 7.2 gigs of RAM being utilized.  By CD’s it will likely be about 7.2 x 3 = 21.6 gigs.  That is a lot of memory to have open at one time.  Does this mean you can’t open a Revit file if it requires more RAM than is installed in your computer?  Not at all.  It will do it’s best to open the file.  First it will fill up your available RAM, and then start cashing to your hard drive. That is when you watch the “busy” wheel in windows start grinding away at your profits.  There are some Strategies that will help manage the memory being used.

They include :

• Strip the models
• Workset management
• Family Files
• Hardware Helps
• Looking to the Future

Hosted or unhosted that is the question

When developing your content for MEP in particular, the choice to make content hosted or not can have some long term consequences.  Consider if your company will work in an environment with all content in one model, or if the architectural model will be linked in to your MEP model.  If you're working all in one model, then the wall hosted, and ceiling hosted objects may have some advantages.  If you're working with an architectural link, then you will likely want to consider unhosted families with the occasional surface hosted.

For one, with a link, there are no walls or ceilings, but all surfaces.  If you are working all in one model, then the ceiling hosted objects will cut the ceiling leaving voids for the ceiling grid. Another thing to always remember with MEP objects that are hosted in any way, if the object they are hosted to gets deleted, they become orphaned. At best they stay where they were, and occasionally they get lost out in left field.  More recent releases are better about not changing the positions of objects, but they can still get left behind.

Let's say the ceilings that lights are hosted to get deleted, and a new one created one foot higher, the lights will now be too low, the lighting calculations will be wrong, and the plenum space coordination is now shot.

So now let's consider the unhosted option workflow. During the design development phase, often the ceilings are not developed enough to safely host devices to, without knowing you will need to re-host them again later. There are many workaround to this for hosted content, all with some undesired side effects.  If your content is unhosted, it still needs a level reference, and you can set a height offset.  Later you can use excel to synchronize the space heights, and your light height offset values and get most of your lights in the right place at one time.

Syncing Data with Excel

There will still be some fine tuning for spaces with tray ceilings and such, but those should be specialty spaces that get more attention anyway.

I work @ CASE!

I am so excited to announce that I now work with the brilliant folks over at Case! I'm about to board a flight to NY to meet my new Co-workers. More on this to come in the near future. I think they just called my seat. 

I don't like Mark.

Here is my problem with Mark.  He marches to the beat of his own drum.  He continues to populate false and bogus information without any relevance or even context.  I'm referring to the property of Mark value in Revit.

What does "93" mean regarding this piece of pipe? Absolutely nothing.  It was automatically generated upon the pipe creation.  Some where, I must have set or reset the Mark value to some number, and it kept counting up to this pipe being number 93.  It is bad data that is constantly populated.  Well, why do I have a problem with this? While small in stature, little bits of data add up. Every element in the project has now several characters worth of bad data. And like pennies, they add up to dollars. Not to mention that too frequent occurrence of being populated with a strong of 50+ repeated characters.  Then when say a piping layout on the first floor is copied to the same place for the next ten floors, then Mark is hopelessly irrelevant. 

And should someone actually want to use Mark to indicate the particular unit name, then they have to delete bad information to make good information. And if they wanted to tag all elements using Mark Value can you trust the elements where it just kept counting. The property is bogus it may or may not be relevant it may or may not be accurate. So now someone has to go back and check all of them to see if they're correct or at least the ones that they want to be correct, not necessarily all of them. 

Yeah Mark is a no go for me. I say get rid of them. Don't use them! Create your own parameter for the values that you do want to schedule then you can clear out all the values of Mark with a clear conscience and actually reduce the file size some.

Rant over. 

Little Known Trick with Worksets & View Filters in Revit.

When you are setting up the properties for a view filter, you may find you would like to use the workset of an object to filter by.  If said object happens to be in a linked file, you don't have access to filter by the worksets within the linked file.  That is unless you have a workset named exactly the same in your file as in the linked file. Then the workset is available, and it works!

To me, the biggest downside to this technique is you must create worksets in your model that will likely be empty, and could cause confusion for others working in the model.  So use with caution.