Jump to content

Best BIM practice - with workgroup references


Bob Holtzmann

Recommended Posts

I recently looked at Nemetschek's example project files in the BIM section,

http://www.nemetschek.net/bim/projects.php

In this section, there is an example file (Alexandria Lofts) for utilizing BIM in construction drawings. But the Alexandria Laundry Lofts lacks the optimal approach to using BIM in the project. Why bunch everything into one huge file (in this case, 80 MB)? That file could only be accessed by one work station. If the drawing sheets were separate files, and the building model was its own file entity, then workgroup references can take care of drawing management over a much wider network. More than one architect could access parts of the architectural set. And if there were engineers on the network, their drawings could reference the same building model file, and a true BIM network could exist - after all, BIM is all about sharing over a network - perhaps it should be called BIMN.

This relates to a recent tour I took of a major local engineering/architectural office (Jacobs), where they presented an example BIM project of a government office building, with lots of 3D presentation, and a full set of architectural and engineering drawings. I asked the moderator if the office used only one building model, and he replied that they used three building model files - one for each department. They had to duplicate the building model THREE times for three departments - one for architectural, one for structural, and one for MEP. This is was done probably because in Revit, the building model must reside in the same file with the drawings, and file size became a problem. The presenter did emphasize that his team was using Revit's BIM capabilities to its technical limits, in files of over 150 MB in size. Hence we get back to the problem of putting everything in one file - not the best practice.

Link to comment
Guest Frank Brault

In fact, this project started out life as a single file by a sole practitioner. This particular example serves to demonstrate that the process of information modeling can be efficiently employed in a single file if circumstances warrant.

As of VectorWorks 2008, the software offers true referencing. There is another example project that demonstrates the use of this feature in a multi-file format located here:

BIM in Practice

Check it out...

Link to comment

Using the true external referencing in VW 2008 has become the way to go in ordering drawing files for me, even as the sole drafter. I have always avoided the megafile approach, ever since I lost a file or two due to a software crash. It's better under that circumstance to lose work on a corrupted drawing or two instead of the entire drawing set. The backup system helps, but I've had a corrupted backup file, too, possibly due to a server failure.

There may be some benefits to a megafile, but I just don't see any. I had a look at Ellicot Heights, and it seems to have even bigger files, with no external referencing.

Link to comment
The backup system helps, but I've had a corrupted backup file, too, possibly due to a server failure.

We have a lot of backup redundancy in my office now (including triple rotation offsite backup and Time Machine) but the little helper that keeps on saving the day is VectorWorks' built in backup, which we use to backup everything anybody is working on to their their own local hard drive every 50 operations.

Link to comment
Bob-H,

Follow the instructions in the whitepaper pdf. The building model in the file "Building Model.vwx" is, in fact, composed entirely of design layer viewports that reference external files in the "Level_Plans" sub folder.

Jeffrey,

I've reviewed parts of the white paper. I concur on the use of the Building Model.vwx to externally reference the Level Plan files, but if the Building Model.vwx only references plan levels, how did it get so damned BIG (170MB)? It crashed my VW program, and I have 2gigs of RAM. The Building Model's references, the level plan files, add up to only 50MB, which is only a third of the Building Model.vwx file size, so there must be something else in there using that extra 120MB of data.

Link to comment

Workflow is an area we struggle with daily in our office. And though referencing capabilities are great in theory (and many times practice) in the VW2008 program, we continually run into issues with files that are either outputting or inputting references failing. And by failing, examples included files that reference one another or have multiple files will ALWAYS at some point become nonoperational (they will crash upon updating references, saving, or will not open at all). And mind you Jefferey, I've seen what you've done in the BIM in practice area, but when I've tried to duplicate your structure I run into similar issues... may be our network though I admit.

Which brings me to Christiaan: I've worked with my files backing up to my hardrive (actually at 50 ops as well), but once a file gets larger than a day or two's worth of work, it take a couple mins to save. With that said, I'm certain you draft as fast or faster than I, and I find myself saving every couple mins some days... don't you find this slows down your work flow dramatically?

Link to comment

Jeffrey,

Took a look again at your file structure on Ellicott Heights last night and am going to to try to duplicate it on my new Mac with everything off network. I was wondering though, am I correct in assuming that this example and in general your projects are done via networks? If so, are there certain "requirements" you start getting into with networks or at this point do I start looking for an IT guy to hire?

Thanks in advance.

Edited by C W
Link to comment

Cory,

Actually, this was all done on my 1st generation 17" MacBook Pro w/2 GB RAM. I set all my referencing to "relative" and made sure I had a good "root folder" and simple folder structure. Once I completed the project, I copied it all to a server and could access it from there.

Things to consider when using networks:

1. Network OS vs. Client OS. If they're are both the same, usually few, if any problems. I know there are plenty of anecdotes of problems, even with the same OS. If a Mac OS is looking for a Windows Server OS, I would be sure to use Mac 10.5, as it is documented to be more robust with WinNetworks. Experiment with both SMB and AFP connections. I've been using AFP on a Win 2003 Server.

2. Reliable wiring and switches/hubs. You'd be surprised by how many problems have been caused by faulty/misconfigured network hardware pipelines.

3. Naming schemes. Regardless of whether a network is used or not, follow the best practice rules of path/folder/file names:

a. Don't use any "special characters", period.

b. don't use periods, except to add file extensions.

c. Don't add file extensions manually, if the program can do it for you.

d. Use only any upper/lower case letters, numbers, dash and underscore.

e. Avoid blank spaces for cautionary purposes.

f. Keep names as short and sweet as possible. As they add up over longer/deeper paths, you can get into trouble.

g. Keep folder organization/depth to a minimum. The more complex you make it , the harder it will be to manage and troubleshoot.

Link to comment

Wow! Thanks for all that. I'm go over these items with our office manager first thing Monday. I hope you understand that when I and others complain it just due to frustration... you guys at NNA due a great job! Good luck with the launch on Monday... can't wait to explore 09!

Link to comment

Bob-H,

The simple reason the file is so big is because I have the "Save Viewport Cache" preference turned on. This preserves the last saved view of all VPs on all Sheet Layers. The Ellicott Heights "Building_Model.vwx" file has many Sheet Layers and VPs to create a Design Development styled drawing set.

From your explanation, I can see now how the file size got cranked up. It's for this reason that I've adopted the strategy of using only one file per sheet (or one file for a few sheets). This can help to isolate the annotated plan sheets from the rendered perspective sheets, and speed up the viewport updates where I need them. The external reference files make all this possible. I learned to do this from AutoCad, along with always keeping the reference path relative to adjacent files, for archiving to disc. I usually title the externally referenced source files as "x-site.vwx", "x-plan-1.vwx", and so on (another AutoCad influence). This kind of rigid file system is necessary when a viewport update can take hours, and there is no way of canceling it in VectorWorks 2008 (maybe this will change in Vectorworks 2009).

Link to comment
  • 2 months later...

I have been playing with the BIM in practice samples and they keep crashing VectorWorks. I am not able to work with them at all.

This is a concern because I am starting a large project and we just purchased upgrades to VW2009 for all our computers.

I have installed the first service pack and it seems I am having more trouble with these samples since I I stalled the service pack.

I will be setting up this big project by floor and not all in one like the examples but I hope it isn't too much for our computers. Most of the other computers are slower than mine. I will need to set this project up similar to the Elllicot heights sample. It is no where near as big as that so I hope we will be ok.

I would like to hear some input from others using 2009 regarding what computer hardware they use and the size of projects they work with.

Link to comment

You should be able to handle a project over a million square feet on at least 150 acres with 20-24 buildings comprising the total. It all depends on how you split up the data in the various files so not any one file has to much data. You can have a master site plan file that is over 1gb in size as the largest with the remaining buildings each around 120mb and still be able to work. And this all in 2008.

Link to comment

Thanks for the replies. I will be setting this project up by floor but I would like to be able to have a master file with all my drawing sheets together to manage title block info and issue dates. Otherwise I might as well do what we always do and reference a border into the drawings. This is kind of off topic but I have my head into this right now. I have made a custom title block and I like the drawing setup routines that insert and manage the Tblock info. I noticed the issue data is a separate record. Do I link that to the i-info fields Like I did with the project and sheet info?

With the Ellicott Heights project I did convert them all to 09vwx and I was able to browse through the files to see how everything was structured but if I try to select something or edit an object it crashes. It did the same with the Laundry Lofts sample too.

Link to comment

The building model in the file "Building Model.vwx" is, in fact, composed entirely of design layer viewports that reference external files in the "Level_Plans" sub folder.

I know. I designed it and modeled it myself.

Hey Jeffrey:

I figured you would be the best person to ask this question: How would you create associative dimensions and annotations on sheets in the Building Model.vwx file?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...