License Delivery maintenance is expected to occur on Saturday, November 30, between 8 AM and 11 AM CET. This may cause a short 3-hours outage in which license-related tasks: license key upload, download, update, SSA validation, access to the license pool and Graphisoft ID authentication may not function properly. We apologize for any inconvenience.
Project data & BIM
About BIM-based management of attributes, schedules, templates, favorites, hotlinks, projects in general, quality assurance, etc.

Large drawing file of a building with many smaller projects

Anonymous
Not applicable
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
35 REPLIES 35
Anonymous
Not applicable
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.
Link
Graphisoft Partner
Graphisoft Partner
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.
Anonymous
Not applicable
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.
Link
Graphisoft Partner
Graphisoft Partner
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.
Anonymous
Not applicable
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.
Link
Graphisoft Partner
Graphisoft Partner
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.
Anonymous
Not applicable
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.
Link
Graphisoft Partner
Graphisoft Partner
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.
Anonymous
Not applicable
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.
Link
Graphisoft Partner
Graphisoft Partner
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.