topic Re: Large drawing file of a building with many smaller proje in Project data & BIM

Large drawing file of a building with many smaller projects

Anonymous — Wed, 18 May 2011 18:57:10 GMT

I just upgraded from AC12 to AC14 and the BIM server. I am about to start working for a client with a large (1M SF) building and I will, hopefully, have many small projects within it. How do I keep each project separated so that I can do complete project documents without having a crippling number of layers.

I under stand that I should consider using linked instead of embedded libraries. I don't know if hot linking will let me create floor/ceiling plans, elevations, schedules, etc. for each individual project.

Thanks

Re: Large drawing file of a building with many smaller proje

Anonymous — Fri, 20 May 2011 12:10:37 GMT

Well one way could be to treat all sub-project's as single project's and then link them all, as module's, to a main project-file "the mother ship" for coordinating and overview.
Project name MP.pln
Project name SP1.pln
Project name SP2.pln
Project name SP3.pln . . . .
MP= Main Project, SP1=SubProject1 . . .

This could also be TW project files.

As for the layer issue I don't understand why you should end up with a "crippling number of layers". If you use the same template file, With a "complete" layer-list, to start all projects you shouldn't have to worry.

Re: Large drawing file of a building with many smaller proje

Anonymous — Fri, 20 May 2011 12:30:27 GMT

Lasse,

I do want to keep each sub project as its own individual project so that I can have Schematic, Design Development and Construction Document set for each one.

Are each of the sub projects a separate .pln file?

What I have tried to do to manage the process was to assign layers to each project. In other words, A-WALLS-INT.Project1, A-WALLS-INT.Project2 and so on for each layer type. If you have 10 projects within the same building envelope then you can see where that is heading.

Maybe there is a tutorial from Graphisoft that explains the module linking process you describe. I will do some research.

Thanks

Re: Large drawing file of a building with many smaller proje

Anonymous — Fri, 20 May 2011 13:10:02 GMT

Yes! Each sub project is a .pln.
You can link an entire .pln file as a module or choose floor by floor.
As for the layer management I would strongly advise to keep the same layer-list through the hole project.

I recommend keeping Schematics, Design Development and Construction Document's inside each sub-project. At least schematics and construction documents. This will keep them apart and there will be no need for sub-project specific layers.

But!

As you "link" these sub-project's to the "mother-ship-file" you will be able to keep them apart as they belong to a module. Each module can be assigned to a specific master layer ( Module-Project1, Module-Project2 . . . ) which controls the entire module. So you can choose to show/hide, lock/unlock whatever sub-project you wish.

Re: Large drawing file of a building with many smaller proje

Anonymous — Fri, 20 May 2011 13:16:21 GMT

Lasse,

One final question. Does each sub-project.pln contain the base drawing elements of the entire main project? All the exterior walls, other existing tenants at the time, etc. Or do you cut only the area that sub-project in located in from the main file and paste it to the sub-project.pln?

Re: Large drawing file of a building with many smaller proje

Anonymous — Fri, 20 May 2011 13:38:03 GMT

That depends on the project and as I don't know the project it's hard to give a good answer.
I have experience of residential projects where main project have been divided in eg:
-Exterior walls module (all )
-Apartment module ( area )
-Bathroom module ( area )
-Kitchen module ( area )
etc.

I hope this gives you an idea of what to do and how to divide the project into smaller pieces.

Re: Large drawing file of a building with many smaller proje

Link — Fri, 20 May 2011 20:55:31 GMT

npacella wrote:
Lasse,

One final question. Does each sub-project.pln contain the base drawing elements of the entire main project? All the exterior walls, other existing tenants at the time, etc. Or do you cut only the area that sub-project in located in from the main file and paste it to the sub-project.pln?

We often do this. We hotlink the main file back into the module file(s). We put in on a master layer called 'MODULES: BACK REFERENCE'. Just be sure to break nested hotlinks.

An alternative to hotlinking the solo projects or teamwork projects directly, is to set up a publisher set to save each story as a module file. (.MOD) and hotlink those. This method gives you more control over what is hotlinked, since you assign layer combos to what is published, is much easier to manage hotlinks and is more user friendly as you can always see exactly what each specific placed module is, simply by hovering over it and reading the element information tag.

This is the method we use to do exactly what you want to do. The difference with us is that our policy is to publish documentation only from the main project. Consequently we only have TWO files. One 'Master' (the main one) and one 'Module' file. The module file has all of the sub-projects, as you put it, on thoughtfully structured stories. These are both teamworked, so it means that all of our users only ever have to join two projects, not six or seven.

And since every project is set up like this, including high rise projects, multi-res projects etc, it's very consistent and intuitive.

It's a big step for anyone new to hotlink moduling, but well worth learning IMHO. If it's too confusing, let me know and if there's enough demand I may create a screencast of the process.

Cheers,
Link.

Re: Large drawing file of a building with many smaller proje

Anonymous — Sat, 21 May 2011 00:36:14 GMT

Thank you Link. I will let you know if I need you to create a screencast.

Re: Large drawing file of a building with many smaller proje

Laszlo Nagy — Mon, 23 May 2011 08:38:44 GMT

npacella wrote:
Maybe there is a tutorial from Graphisoft that explains the module linking process you describe. I will do some research.

In Part 2 of the Collaboration ITG, in Step 5 of Chapter 6 you can see examples of using PLN files and TW2 shared projects as modules:

You can download the ITG and watch only Step 5 of Chapter 6.

http://www.graphisoft.com/education/training_guides/#COL2

Re: Large drawing file of a building with many smaller proje

KenMcN — Mon, 23 May 2011 09:05:03 GMT

Link wrote:
The module file has all of the sub-projects, as you put it, on thoughtfully structured stories. These are both teamworked, so it means that all of our users only ever have to join two projects, not six or seven.

Link
This sounds better than our system of using separate files for each building hotlinked into a 'context' model (not least as it makes it much easier to keep attributes consistent).

Can you give some more detail about the storey setup? This seems to be the area most likely to cause confusion, but overall it could be a very good way to work.

Thanks
Kenny

Re: Large drawing file of a building with many smaller proje

Anonymous — Mon, 23 May 2011 21:37:58 GMT

Kenny here are dome other things for you to consider:
Attributes
In the central file all layers etc are merged into one. To avoid different layers for the same thing consider a template file. Demand all project personnel create any new layers, materials etc in that file and then use attribute manager to distribute this to other files. Sounds a pain but saves a whole world of pain down the track.
Stories
This is tricky and IMHO can be a real pain. Multistory hotlinks bring the source data to the target file. That means the story setup of the target file is adopted. The workaround is to individually place each story and then elevate each to the desired levels in the target file. Where this is very messy is where you have SEOs between different stories. In the past I could recreate them but in 14 it seems the operators must be native to the target file (not impossible, these can be made and put on a hidden layer). I have not tested it but the other issue that may occur - if you want to fight the local story setup - is that elements in a wall (say) placed by relationship to story may not cooperate. In the 'worst' cases it may be better to save out library parts of the buildings for the site model. In fact where many large complex buildings ate involved this is a great way to tailor the file for what is needed and avoid bringing in huge quantities of data- the whole building.

Hopefully these give you some food for thought.

Re: Large drawing file of a building with many smaller proje

Link — Tue, 24 May 2011 05:19:51 GMT

KenMcN wrote:
Link
This sounds better than our system of using separate files for each building hotlinked into a 'context' model (not least as it makes it much easier to keep attributes consistent).

Can you give some more detail about the storey setup? This seems to be the area most likely to cause confusion, but overall it could be a very good way to work.

Thanks
Kenny

Please find below an image showing an example list of our story structure and how we create our Module Publisher Set (using AC15).

We use spare stories ( that remain spare until the user needs one) because inserting new stories breaks existing HLMs, as listed as a downside below. And we generally don't publish any of the spares. New stories can be added above and below the existing structure, just not in-between.

The 'EXPORT: MODULES' viewset is a clone of the Stories in the Project Map. All views have their ID set to 'None' and all have the same 'EXPORT: MODULES' layer combo, scale, PSD, penset, 'EXPORT: MODULES' MVO, dimension standard and zooming. The 'EXPORT: MODULES' publisher set is simply a shortcut of the viewset. When I modify the company template and share it on the BIM Server, I typically set up all stories as spares (eg. 'FLOOR PLATE: SPARE'). Then all the users need to do is rename the story, and the publisher set updates accordingly, using my marker referencing philosophy.

The Master file has module 'master layers' that match the names of the stories/views/modules. Eg. MODULES: CORES, MODULES: FLOOR PLATES, etc so we have full control over each module type. Phasing requires a more complicated moduling approach.

We use 'OPTION' stories for optioning. We never actually publish the option stories. It's just a simple copy/paste between those stories and the ones above, and a republish.

This file is simply a 'construction area' and no drawings or 3D views come from it - only the published module files, which are 'assembled' in the Master file.

As I mentioned here this works very well.

The upsides:

-In the 'module' file you can trace reference between plans nicely.
-We don't experience any issues with multi-story library parts (as we export the current story only).
-Publishing is very simple.
-MOD files are tiny.
-Updating is very quick.
-Relinking is easy & intuitive.
-Hovering over a hotlinked MOD file reveals the exact name of the MOD (not just the file it comes from), assuming your naming conventions are descriptive.
-Attribute Management is very simple.

The downsides:

-Inter-story SEOs don't actually hold their relationships and can't be re-SEO'd in the Master file. (You can use Trim to Roof instead in some cases, or an intermediate module file according to GS).
-If new stories are inserted into the 'module file', all the links will break (this is a technical limitation to date, and is why we have more than enough stories preset in the module file, and add to the top/bottom if we must.
-If new stories are inserted into the 'module file', the cloned view name does not automatically acquire an ID set to None, so must be set manually.
-A dimensioned structural grid needs to be re-dimensioned on each story once it is placed in the Master file (the grid remains visible on all stories, but not the dims).
The publishing path/location of the MOD files is not on the BIM Server as such, so can cause problem if teamworking remotely, with a VPN into the folder too.
- Whilst the name of the MOD file is traceable in the hotlink manager, the (name of the) source file isn't.

It looks like an equal argument, but from a practical point of view, there's no way we would go back to hotlinking entire projects anymore. It's really slick. I bet if you try it once, you'll never go back.

I often have my users comment how much easier it is this way - especially when they have to revisit an older project set up 'the old way'!

Cheers,
Link.

Re: Large drawing file of a building with many smaller proje

Anonymous — Thu, 26 May 2011 08:41:57 GMT

Link wrote:
We use spare stories ( that remain spare until the user needs one) because inserting new stories breaks existing HLMs, as listed as a downside below. And we generally don't publish any of the spares. New stories can be added above and below the existing structure, just not in-between.

The Master file has module 'master layers' that match the names of the stories/views/modules. Eg. MODULES: CORES, MODULES: FLOOR PLATES, etc so we have full control over each module type. Phasing requires a more complicated moduling approach.

We use 'OPTION' stories for optioning. We never actually publish the option stories. It's just a simple copy/paste between those stories and the ones above, and a republish.

This file is simply a 'construction area' and no drawings or 3D views come from it - only the published module files, which are 'assembled' in the Master file.

Cheers,
Link.

I am not quite sure I understand you.
So in my example, I have an 23-story high-rise. It is residential, except for the ground floor that is commercial.
So, from first story to the 11th I have 8 flats (four different (flat A, B, C and D)- 2 of each variation). But from 1st to 6th there is difference in construction elements. walls are thicker, so flats on those stories are smaller a little bit. from 11th to 22nd I have same flats with small difference - one flat C and A has become flat E, so there are 2 B's, 2 D's, 1 A, 1 C and one E. Last two stories are completely different so there is no modules.

What I did is that I set modules for each flat and it's variation. I have set module for construction (load-bearing) walls and columns, which has three variations (1st-6th, 7th-11th and 11-22nd), and slabs with stairs are two modules. I have saved those module inside master file using ctrl+c and save as module from clipboard. after that original elements were replaced with modules, so in master file I have only modules, but I have to edit them in separate archicad or on the stories they were created. In separate archicad I don't have the rest of the building so I have to copy paste floor on which that module is placed. I copy/paste it into worksheet and then trace it under my module. then I modify it and save it and in master file update and there it is.
For me it is important that each flat is separate module, since archicad can than calculate the number of the same flats.

what I don't understand is how do you create those modules in module project.
Do you have whole stories as one module?
if so on which archicad story you create sub modules (modules of flats)?

It would be nice to have video tutorial on that.

Re: Large drawing file of a building with many smaller proje

Link — Thu, 26 May 2011 11:18:24 GMT

Well until I can get to creating a video, I can tell you that the creating a module from the clipboard is the big difference here. If instead you put the information that makes up each of your existing modules, onto their own unique story in the module file then you only have one place to edit them all. And you can have both the 'master' and 'module' files open at the same time for speed.

All attributes between these files should be identical and elements are modeled and drafted on the same layers they would be typically. When placed in the master file, the modules are put on their respective master layers to control visibility as whole modules. But since the information ~inside~ those modules are on the typical layers, you can still use your usual layer combos to create your views.

In the module file, you can place modules within modules and still continue to publish them for placement into the master file (as long as you include nested modules in the options). For example we often module typical kitchens (each created on their own story) into our units (each created on their own story). This is also done via publishing modules from the same publishing set. Then place the unit with the nested kitchen in the master file. The upside is that the kitchen can be updated independently of the unit. You could also extend this idea to nest units into entire floor plates, although we prefer to assemble them all in the master file for better control, particularly visibility.

The stories of the main model in the master file can be published as modules and 'back referenced' into the module file in a similar fashion, wherever needed. Obviously the master layer of those modules is turned off in the viewset that is published with all the modules, so they don't go full circle back into the master file!

Hope that helps, but it doesn't read all that well, so maybe I'll get onto that video sooner rather than later!

Cheers,
Link.

Re: Large drawing file of a building with many smaller proje

Anonymous — Thu, 26 May 2011 23:05:34 GMT

Link,

To help motivate you to get this happening into a Tutorial Video you could look at providing a presentation at the next Brisbane User Group Meeting. 😮

I am able to follow & think I completely understand what you are saying but also look at it & think that there is a certain amount of assumed knowledge involved with what you are saying as well.

Re: Large drawing file of a building with many smaller proje

Link — Mon, 27 Jun 2011 06:10:52 GMT

Yes, it certainly does take some assumed knowledge. It's an advanced concept.

Here's a couple of screencasts from our blog that may help explain our moduling concept:

Part 1 of 2: Creating and Publishing Modules

Part 2 of 2: Placing and Updating Modules

Keep in mind that once placed HLMs can be copied and pasted around the project (with grouping enabled) and still keep their hotlink.

And modules of the entire floor can be produced from the Master file and placed back in the module file as a back reference.

Cheers,
Link.

Re: Large drawing file of a building with many smaller proje

Anonymous — Wed, 29 Jun 2011 19:23:41 GMT

Link,

Thanks this is extremely helpful.

To clarify: the drawing file that you use in the first video is a separate ACad file from the master file. It is only used to create published modules that can be imported into the master project file, assembled by floor and then the project documents are created from this second ACad file. You need two ACad file for each project.

You mentioned that all of the elements in the module are placed on your standard layers. I was wondering why all of the elements in a particular layer that may be in other modules or in other locations on the story aren't visible as well.

Re: Large drawing file of a building with many smaller proje

Link — Wed, 29 Jun 2011 21:56:48 GMT

Hi Nick

Glad to see you're getting some value from this. I must admit that of all my tips, I would put this one in the top three for sure. Such a time saver, especially when working with larger teams.

Anyway to answer your first question, yes that is exactly right. Two files; one 'module' file and one 'master' file. I've seen the same setup using over 20 files with more than 570 hotlinked stories. What a nightmare trying to figure out what came from where and why. This method is dead obvious and easy for anyone to join in and grasp.

I am not sure I follow your second question, so I will just clarify what I'm doing. Firstly, every attribute (including layers and layer combos) are identical between the two files. All elements go onto their unique layers (ie. Walls on wall layers, notes on notes layers, non-published info on hidden layers, etc). The data for only one module resides on each story - to separate them and to make best use of trace referencing. The layer assigned to the publishing views hides the hidden layers and leaves just the things we want in the module files.

When placed in the master file, each different type of module goes onto it's respective master layer. This allows us to hide the module as a whole. For example, we can hide all of our units, or even just show particular unit types by showing their master layers.

But since the elements inside the modules were originally placed on their unique layers, when can still create floor plans, RCPs, electrical plans, etc. We just show the master layers, but hide/show the individual layers within. Since these are the same layers as any similar elements created directly in the master file, it all flows through to our layouts and publisher sets perfectly.

I hope that answers it for you. Let me know if it doesn't or you need more info.

Cheers,
Link.

Re: Large drawing file of a building with many smaller proje

Anonymous — Wed, 29 Jun 2011 22:07:39 GMT

Yes it does, I think. The 'story' in the module file is somewhat arbitrary and not related to the story that each module ends up on in the master file. It just keeps them separate and easier to view and publish individually.

Re: Large drawing file of a building with many smaller proje

Link — Wed, 29 Jun 2011 22:24:25 GMT

Yes you've got it.

The story that the module data resides in in the 'module' file has no relationship to the story it ends up on in the 'master' file. In fact they are usually placed & copy/pasted over many different stories.

The stories in the 'module' files are just containers of information. That said ArchiCAD still remembers what story a module file was created on, so if you go and insert new stories in the 'module' file after you have published some, all the placed HLMs will break. I consider this a bug and have made GS aware if it. You can add more stories to the top or bottom, you just can't insert any. That's why I put spares in.

Cheers,
Link.