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.  

How to Start Programming Revit Add-ins.

Part of the focus of this blog is how to manipulate and take advantage of the Data being generated by BIM. I'm happy to say I'm well on my way to learning to swim in this sea of data! I have started learning how to program the Revit API in C#.  I had some programming experience in college about ten years ago and in a different language.  So far, I have successfully written five different add-ins.  Yeah me!

Here is what I have done to learn what it takes.

I downloaded and installed the Software Developers Kit from Autodesk Developers Network.  I also tried several good tutorials they have available.  While this was good, it didn't give a lot of explanation to why things were done the way they were, especially for a novice programmer. Also, much of what I found available in this was written in C#, which inspired my learning the language.

First a free online Fundamentals for Beginners C# Programming course from Microsoft.  This gave me a good understanding of the basics. It also talked me through downloading and installing Microsoft Visual Studio Express 2012.  The express doesn't mean it runs faster. It simply means it is the free version with several features missing.  That topic could and likely will be another blog entry to itself.

Knowing C# alone is only part of the puzzle.  Next you must learn the specifics of using the Revit API in C#. I choose to purchase the Udemy on-line course from Harry Mattison, Founder of Boost Your BIM. The man knows his stuff, and does a good job of explaining it.  This course is what finally got me off the ground and running.  

Another training tool I found very beneficial was Don Rudder's book on programming for the Revit API, (also an excellent resource).  Most if not all of his examples are in Visual Basic. This I have learned is not a big deal for experienced programmers to utilize and swap between several languages, provided they are all part of the .net framework.  I won't pretend to understand all of that short of saying they are somewhat interchangeable.

Also along the way has been countless Google searches on topics, advise from friends in the programming industry and a trip to Autodesk University (focusing on API classes).  One class that stood out to me was David Rushforth's Automate your Revit-Based Software Workflows: Let the API Do the Work.

In the not to distant future, I hope to start selling some Add-ins through this site. I have several ides already. Do you have any suggestions/requests? If so, please leave a comment, or message me.

Divide and Conquer

The ‘when to divide’ and ‘how to divide’ topic has a million shades of gray.  The process does have some overhead time required to setup.  When needed though, there seems to be three schools of thought on how to divide a project. The first is across the match lines. The second is by floor. Then the third is by discipline.

Well, for Architecture it makes sense to be able to divide by the match lines, but not for MEP. As of Revit MEP 2015, system information cannot be passed through a linked file.  Yes, you can tag through a linked file, but that is not the same as passing system information along.  If the electrical panel that serves an outlet is in a different file, then it can’t be added as a load to the panel.  Air Handling Units in one file, can’t add CFM’s from terminal units in linked files.  Largely, this approach just does not work for MEP.

The second approach of by floor has the same limitations. If the systems need to be able to connect vertically though the building, they won’t be able to. This leaves only one viable option left, dividing the model by discipline.

On large projects dividing the models is a must to gain efficiency, but on smaller projects, where is the cut-off for a return on the time investment?  Buildings 30,000-50,000 Sqft and smaller are generally manageable as single project files.  For larger projects, it makes since to create separate Revit MEP models. I prefer to divide them per trade (Electrical, Plumbing, & HVAC), then interlink each into the others by placing them on separate worksets unique to each linked file.  Finally setup the central file to inquire as to which worksets to load upon opening. If the workset for electrical is not selected upon opening the HVAC model, then none of the electrical objects will be loaded into active memory.  This can free up huge chunks of memory.  Dividing worksets into logical chunks helps with linked files even more.  Let’s say the electrical model is linked into the HVAC model.  To coordinate the ceilings, the workset for lights can be the only workset loaded into the HVAC model.  To manage the worksets within linked files use the Manage Links tool as shown below.

Strip the Model

When the architect submits a model for use as a background, it is their working model.  It has lots of sections, elevations, drafting views, 3D views and schedules that are not needed as a background.  So open their model up, and delete out as much as possible.  Delete every 3D view, every section (unless you have a view linked directly to that section view), every schedule, every drafting view, every legend view.  Make these models as striped down as possible.  The same applies to structural.  In fact you can delete out every view leaving only one view in the project and all the geometry remains. Now that all this has been deleted, purge the files.  Purge, is found under the manage tab.  It removes any family and family types not currently in use.  Typically after this process is performed the finished files size is between a quarter to a half the original file size.  Your mileage may vary. 

Hardware upgrades

Where will you get the most bang for your buck?  On a per workstation basis, RAM. At least eight gigs to start with. If that isn't quite cutting it, look into getting some solid state hard drives. Remember after your RAM gets full, it cashes to the hard drive. The solid state drives out today have data transfer rates of six Gigs per second. If that doesn't work out, it might be time to consider looking for new workstations. All the aforementioned hardware recommendations should be included in the specs for your new workstation.  Revit is now multi-threading for opening and synchronizing process, along with some others, so the more cores on the processor the better. This makes for huge time savings.  Video cards are about the most confusing topic to add to this list.  The differences in performance between a good gaming card and a good professional grade graphics card can be barely noticeable, but the price certainly isn't. I will say that the more RAM your video card has on it, the more it frees up from your system.  That can be substantial for performance if your system is struggling. Lastly if I.T. doesn't already have a gigabit network throughout the office, make plans to get one.