Taking Revit Server "off-road"

Borrowing from the title of a recent post by Mr. Revit OpEd I wanted to bring up what I think is a rather critical point to be aware of if you're thinking of running Revit Server on your laptop to solve what is often termed the "Construction Trailer" problem. I've been in touch with the two sets of folks who I know have installed RS on a Win7 computer, that is Mr. Baldachinno and Mr. Cone (Beck / Aaron Maller). For David its an experiment in "low cost" servers for a small company. For Kelly & Co. its an attempt to make an easier way for users in a construction trailer to work on their Central Files.

What I want to highlight is if you're running RS on your laptop, so you can "work" on your central files live over the Construction Trailer's DSL connection with a VPN tunnel, is that your user(s) need to learn how to shut down Revit Server gracefully. The very clear and present danger here is that a user in the trailer, simply turns their computer off, or worse yet, "pulls the plug". I can guarantee that you're playing with fire here if your users do that. There is a good chance that at some point they'll corrupt some or all of the Revit data cached locally to their  "server". Autodesk has some clear instructions on how to shut down a Revit Server properly, the problem is, that it involves locking the whole infrastructure while you take down whichever local server you're shutting down. The good news here is that there is a much smaller risk to the data on the actual Central Server. It does a good job of protecting itself and the data it is responsible for, so a Local Server suddenly going off-line should* not affect any of the data at the central server.

Just a word of caution for those attempting to push technology to the bleeding edge and not just the cutting edge.

*Note, I say should, there are conceivably instances where the sudden shutdown of the client or the local server might cause harm to the Central Server data store, but theoretically these should be pretty remote. Worst case is that a lock is left in place on the Central Server due to the "user" disconnecting in the middle of an operation. Keep in mind that when a user SWCs data is committed directly to the Central and Local Servers, and the data is not committed to the project data store until the transaction is 100% verified.

Revit '10 crashing & UIState.dat

A quick search on Google will reveal a number of posts about related directly to the UIState.dat file. Much has been made about deleting the UIState file in order to "reset" 2010's ribbon interface (Autodesk even publishes a tool and instructions). However, I've recently learned that corruption of this file is heavily suspected in cases of Revit 2010 crashing for no other obvious reasons.

As I've made mention before in different forums, generally my firm has held back from moving to 2010. However, its been un-avoidable for a number of reasons, on a number of projects. What has been alarming is the frequency of crashes we've seen/are seeing with users in 2010. Part of this may be in-sufficient hardware (as 2010 simply seems to be more intensive then 2009) or, another reason to blame may be more complex models. Several of our 2010 projects have structure and MEP (one of the reasons they are in '10 to begin with) which even on a small project greatly increases overall memory footprint when all files are loaded.

However, it turns out that the real cause of blame may be the UIState.dat file. I've been told (off the record) by reliable sources that if we have un-explained crashes (no warning, no recovery save, not in the middle of a significant operation) and in the journal file we see  just prior to the journal termination/exception error then there is a good chance that deleting the UIState.dat file will alleviate the crashing.

So far we've deleted the file on two PC's (mine being one) and with fingers crossed, we have not seen more crashes, but we need to give it some more time. I expect we'll be deleting the file from other's PC's in the near future.

The really wacky part was a case last week (while I was trying to enjoy Media Day). We had a user who, when he logged into one of our 64bit remote workstations, the moment Revit finished opening a file, and he did anything to affect the Ribbon, Revit crashed! It turned out that Revit was not creating any type of UIState.dat file for this user (though when I logged in, it created a UIState.dat file for me just fine). Furthermore the user could run Revit MEP without a problem.

Autodesk's only suggestion for this case was to delete the user's local profile from the machine, as there also seems to be cases where the whole local user profile becomes corrupted in some way.

Once the profile was deleted, the user logged back in, and Revit created a UIState.dat file without any problems, and so far has been stable.

Thus, all I can offer, is that if you have random crashes in Revit 2010, and they can not be reasonably attributed to anything else, and your journal file matches up with the above description, chances are you should start by deleting the Dat file, and if that does not clear the problem, delete the user's profile (by the way I take no responsibility for lost data if you do delete a profile, its up to you to know what you're doing, our IT staff already has it down to a science).

I'll also say, that off the record Autodesk is quite hopeful that this issue is resolved moving into 2011, however, even with Beta testing the numbers are simply not there to reveal a problem that is so hard to troubleshoot and hard to even be sure when it is happening. Indeed, to date I've not seen this problem myself in 2011, even though its occurred to me in 2010. We can but hope that this page has been turned.

Room Separation in Group

I was working on a space plan on a project today & came across something slightly annoying.

I created a group for each workstation with it's associated chair. Copied it all over a plan. Then copied the group to the plan above. After doing this for 4 full floors, I then realized that I needed to have room separation lines to create rooms so I could easily color code the plan. So thinking that since I already have the groups I can just add room separation lines to the group & voila I'd be done in 5 minutes flat. Everything was fine until I started editing groups that had been copied to the floors above. All of a sudden after editing a group on floor 1, "random" room separation boxes showed up on floor 1. After some investigation, I discovered that these were actually from rooms on floor 2. Some of the instances of the group their room separation lines were located on the floor 1 even though the group was located on floor 2.

I tried copying & pasting the lines in edit group mode from floor 1 to floor 2 to try & fix the problem but that only made things worse. The groups that were on floor 1 now had their lines on another level. The only solution that I found to work was to delete & replace the offending groups (which is a pain). So instead I created new groups of just room separation lines and spent more time copying those around the plan.

So as a warning: Room separation lines & groups do not always get along.

-K-

When E is not... E?

I was working on a family here at the company, and it turned out we need to use a formula that involved using a Log function (you remember Calculus right? Cause I don't.....). In excel the Natural Log (that is the log taken of e, your handy dandy mathematical constant) is notated with the function ln(). Which is fine and dandy. If you look in Revit help under valid syntax, is conveniently says that the "log" can be taken of any number, what they fail to mention is the base the Revit log function operates in, which is 10, not e (bummer :( )

But....! If you do enough research (or remember enough Calculus) you find out that Logs in base 10, can be converted to Logs in another base, by some simple alegabra. (hooray!) Even better, Revit help clearly states that the function exp() will raise e to the specified power, so therefore we could write:

= log()/log(exp(1))

and we would get the result we need, since a number raised to the power of 1, will simply be the original number. This is good, because theoretically this means that Revit (and or your computer) will use e calculated to the most accurate value the program (Revit) will accept (you're still with me, right?).

Yet, for some reason, Revit's result did not agree with Excel . With a little more help from some friends (read the whole AUGI thread here) it was discovered that the function exp() resulted not in raising e to the specified power, but 10!!! So, exp(1) = 10 in Revit, contradicting Revit's own help documenation!

Now I ask, why would we ever need a function that raises 10 to a power? I can always write: 10^2, 10^2..... I can even use parameters for both values if I need to, 10 is a number, not too hard to deal with. I would much rather have access to e particularly since I need it!

For now, we're using a truncated value for e in our formula, and its close enough, but I would say, with relative certainty that somewhere (quite a long time ago) someone made a mistake...

Not that too many people are running around using Logs and e in their Revit formulas, but with the advent of the new massing tools, it could become a possibilty. Besides, its the principal of the matter, right, we should have access to our standard mathematical functions, and the documentation should be correct!

CSI Revit (Part II): Tracking down the culprit

We left with how to read journal files, and a suggestion on practicing reading them. Today, we're going to talk about where and how they can come in use for some computer forensic detective work.

Allow me to set the scene.

• At Burt Hill we encourage and keep multiple local files when working on a workshare project. This has come in use multiple times, and for multiple reasons. We usually suggest that a user maintain a week's worth, and sequentially overwrite the files.
• A project team has been working diligently to their deadline. Annotating views, drawing details, setting up sheets, running check prints.
• They're busy working the weekend, 12 hour days to meet their Monday evening print deadline.

Sometime late Sunday or Monday morning, someone realizes all the Keynotes are missing from all the views. The team knew they had been there as they had previous copies (digital & physical) of views/sheets that were complete.

The first step, was to figure out what could be done in the short term to deal with the problem. This is where our rule about multiple local files came in handy the first time. Team members were able to immediately start rescuing views by opening old local files and copying/pasting the missing Keynote Tags from old to current.

The next step was to figure out what happened to the Keynote tags, needless to user error was the primary suspect, but, whose error, and when? How many times have we all worked on large Revit projects, and had something "go missing" or something was "deleted" and we are left to wonder, what, who, when, how... Well one of our top users decided to track down what happened.

To start, he looked through the local files, local file history, and central file history to narrow down when the keynotes disappeared. For those who don't know, for both central and local files you can pull the save history from the File menu (see screenshot).

Once he had an idea of where to look more specifically is where the journal files became useful. With some sense of the approximate time to look for, our investigator used the find command to look for keynotes. What he eventually found was this in a journal file...

One of the users on the project had used "Select All Instances" of the keynote family used in the project, and hit "delete". For some reason this user was under the impression that "Select All Instances" was valid only for the active view! As it was, the user was helping our investigator, and was the one to find the four pages of text showing every keynote being selected, it was quite the teaching moment for the whole team.

While it took the lead investigator a good chunk of his day to sort through all the related files. It was needless to say quite useful to determine what had happened, most importantly, to help assure it doesn't happen again. While the copies of files, and back-ups helped with restoring the missing work, and helped to narrow down the time period in which the mistake happened, without the user's journal file there would have been no way to so clearly identify the culprit.

Check back at the end of this week (or beginning of next), for the my wrap up on journal files.

CSI Revit (Part I): How to read the crime scene.

Do you know what a journal file is? If you have dealt with Autodesk support on an extended issue you may have been asked to submit journal files, but you may still not quite know what they are.

Quite simply journal files record all your actions during a Revit session, Revit creates a new journal file whenever you start it, and stops writing when you close it. Under the general tab of the options dialog [Settings menu >> Options] are two choices for how many and for how long you keep journal files. Revit always writes its journal files to the same location; Windows XP c:\Program Files\Revit version\Journals. I would assume that Vista installs maintain a similar structure/relationship. Journals are simple text files (in fact their extension is .txt) and can easily be opened with a program like "Notepad" (my preferred editor for such things). They are always named in the same format "journal.xxxx.txt", where the x's are four digit sequence.

Journal files are pretty interesting things, and can prove handy, particularly when troubleshooting. The reason Autodesk or Revit support likes to get their hands on journal files is because it gives them a window into what the user is/was doing, how the file is behaving, and how the computer is performing. Journal files not only record the user's interactions with the Revit file, but they also record vital computer statistics like how much memory is available, the video card installed, etc; all of which is useful when troubleshooting a problem.

The particularly nice thing about journal files is they can also be "read" by a human. While there is some esoteric code that shows up, it is actually generally possible to read a journal file and understand the actions a user is/was taking. Of course we're not talking about reading a good novel, but as you become more familiar with them, you start to understand the pattern of the language, and thus how to read it. Most commands are listed with simple descriptors like this:

Jrn.Command "DesignBar" ,
"Create a wall , ID_OBJECTS_WALL" Jrn.Directive "JournalDataChainOption" , "Walls", 1
Jrn.MouseMove 0 , 503 , 368
Jrn.LButtonDown 1 , 503 , 368
Jrn.MouseMove 1 , 504 , 367
Jrn.LButtonUp 0 , 504 , 367
Jrn.MouseMove 0 , 936 , 371
Jrn.LButtonDown 1 , 936 , 371
Jrn.Data "Transaction Successful" , "Wall"

To the uninitiated, this looks like a lot of gobbly gook (perhaps à la The Matrix), but if we break it down, we can understand what is happening in Revit. First, the command initiated is the wall tool on the design bar: Jrn.Command "DesignBar" , "Create a wall , ID_OBJECTS_WALL"

Next are any options related to the wall command in this case the chain option is checked. Then, there is a mouse move, presumably to locate the cursor where we want to start drawing the wall, after that there is a Left Mouse button click at the same location to initiate the process of creating a wall, apparently the user's hand was slightly unsteady as there is a mouse move registered before the button is released up again. After that, there is another mouse move to the end point of the wall, then another click to complete the wall. We know that the creation of the wall, and therefore the end of this particular command was completed successfully as there is a "Transaction Successful" line with the key "Wall" to indicate the wall command finished.

Almost all other commands in a journal file follow a similar pattern, I usually try to start by looking for the transaction successful line and working backwards, but you don't have to, particularly if you learn to read the journal files.

Now you might find you journal files tend to look like this:

This is quite messy, but all the lines that start with an apostrophe ( ' ) are comments, also automatically recorded, however they have nothing to do with actual Revit commands, they may just serve to provide additional information, like memory statistics, or the date time code of when a command took place. It is actually possible to scrub a journal file of much of this additional information, but, while I know it can be done, I don't know the details of how it is done.

So you say, what am I to do? Well, you can use the find command (available in even lowly Notepad) to search for specific things. Since journal files are recorded in plain English so to speak generally searching for a keyword related to the command you are looking for is a good start. So a search for "window" will start to turn up any instances of interactions with the window command, or window objects.

If you want to learn more about journals, you might want to start by starting Revit, creating a blank file, then performing some simple actions, like creating a few walls, placing a door or two, make a section, etc. When you finish, close Revit, then go find the most recently created journal file. See if you can trace your actions through the file. You should be able to identify code for every specific command you take. I will warn you that when you switch views, or modify them, you get a ton of additional code that has to do with what the window is doing, you can generally ignore most of that, and keep tracing your commands.

In my next post we'll actually take a look at doing some useful detective work with the journal file, and a real life casefile that I have to share. We'll follow that up with something that I think a great number of people will find extremely useful, so stayed tuned, the season finale is around the corner...