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.

No comments: