Show the correct stories of hotlinked modules

[Norbert Pinter]

Hi,
Recently I joined a project where buildings with different floor level heights are included. Basically a block in the city centre with three existing buildings with three different floor height structure. When I joined the project it was one file. Then we have separated them and linked them to one another with hotlinked modules. It looks good in 3D and on sections, but on the floor plans it is challenging to get the right setup. All the 3 files have the same amount of floors but different floor level heights.
This is where it gets tricky. For example, we want to show the third floor in Part 1 (height +17,45), which is the second floor in Part 2 (+16,30) and the third floor in Part 3 (+18,01). We would like to show them as "one" floor.
And the same thing happens on different floors that we want to show the floors in a different combination than it does currently.
The only solution has come to my mind is to add "fake" stories with zero heights. To stick to the example above, this brings us to that we could show those floors as the third floor in all parts. (Add a story with zero height to Part 2 below the second floor so the second floor becomes third floor.) It's a bit complicated, but I hope you got what I'm talking about.
What is your experience with this? Anything I should worry about? Is there a different solution for this? Does it affect the communication with the consultants if we use IFC?
Thanks!

[Anonymous]

Usually when i menage multiple buildings i show them grouped in the masterplan and the ground floor. For all the other stories i show them one a one. If u want show them grouped u could merge the views of the 3 different floors in one layout.
Your fake story is not the best way for a BIM workflow since the model structure is more important than the layouts.

[Norbert Pinter]

Thanks for the suggestion, Gianluca!
My problem with that is I really want to avoid to make this kind of patchworks on the layouts. Because in that case it is absolutely impossible to send proper DWGs - in the right place of the coordinate system - to the engineers, consultants. If I export DWGs from the layout - which is not a good routine in my opinion - everything is falling apart (the parts of the patchwork will be placed randomly around). I need to have everything right in place therefore I publish from the View Map. But then the floor heights are not good without the fake stories.

[Erwin Edel]

For split level buildings (which this sounds like), we have (cloned) views for the floorplans with the different offsets to the story as needed to show the proper 1.500 mm above level cut for a floorplan. We do stitch these together, as described, but these really are just 'resized' placed views, where you only show the relevant area.

A DWG export of this would export multiple floorplans of the same story, some of them showing the right bits in model space. If you export only paperspace things look fine.

This is perhaps an arrogant stance on our side, but if my consultant is still stuck in 2D AutoCAD world, they can sort it out on their end. I'll happily provide IFC-exports where these problems are a non-issue.

It sounds almost like you are going to be forced in to a 2D workflow for their sake.

This is also possible with worksheets derived from your floorplans, but at that point you are wasting billable hours on your end because your client has made a mismatch between an architect with BIM workflow and consultants who have not adapted to BIM. Which happens all too often, sadly.

[Ignacio Azpiazu]

This has worked for me in those situations:
1 - You start modeling each building on its own BldgA, BldgB,… file, with its individual Archicad levels (B02, B01, 00, 01, 02,…) as if none of the other buildings existed or mattered (during the design process, with better surveys and design changes, this individual-building story-levels-setup is likely to change). This file will produce 'buildng level' drawings, such as stairs plans and sections, facades, etc.
2 - You start modeling the site elements (sidewalks-driveways-utilities-shared podium or basement parking levels, bridges between buildings.) on the Site file (with better surveys, these Site elements and levels will change too). This file will produce 'site level' drawings, including your block plans, block elevations if needed, etc.
3 - You decide which story of each building will show in each of the Site (block) plans. On the story names in Story Settings on the Site file itself (preferably) or on a post-it note somewhere, you write down that structure. You'll end up with something like: S00_A00-B00-C01; S01_A01-B01-C02; etc. There will be 'unconnected' building stories, which you can handle as a mezzanine in a house plan (it is a special, partial plan, which will not necessarily appear on a block plan; otherwise it will appear on a block plan which is blank except for this building story). So with different ground level grade and story heights in each building you will end up getting things like S05_A02-B04-C01.
4 - You publish story modules from each building file into its 'story modules' folder ('A bldg MODs'), and once in the project's lifetime place each of those modules onto the site file and elevate it up or down as needed. When the site file or building surveys or designs change, you may need to adjust the Bldg Story Settings story heights/elevations, and on the Site file elevate the placed modules up or down accordingly.
5 - This works with conventional buildings, where walls and doors in the Bldg files can be shown symbolic. Your Site floor plans will display the correct information for each building, and you don't need to care about cutting planes for these elements. Otherwise things can get trickier, but usually made to work with some thought —for automatic to work everywhere without a thought, one would need the (non-existent) possibility of making 'breaks' in the cutting plane.
6 - Because on the Layer Combination for the module publishing View used for the module Publisher on the Bldg file you decide the elements from which layers will get sent into the Site file, some layers can contain different information on the Site and Bldg files, as required for Bldg and Site views. This simplifies layer structure, views setup.
7 - You may end up needing 'lower level' modules (bathroom, kitchen, office layouts, equipment) generated in a third-level module-production file and getting published, stored and placed onto each of the buildings. For both these and the Bldg story modules you need to decide whether you need to bring in nested modules —nested modules with all their elements will be brought if those nested modules are placed on a layer visible in the module publishing layer combination, even if the elements themselves are not visible in that layer combination; in the Publisher setup options you typically want to check 'break nested modules', and always want to uncheck 'bring visible elements from other stories'.
8 - By default, unless there is some very good reason for proceeding otherwise, all modules get placed on the Archicad layer; a good reason for proceeding otherwise would be for example in multi-unit buildings where you want to 'turn off' unit interiors in ceiling, building, finish plans; in that case you place those modules on a 'Unit MODs' layer, which is hidden in Bldg finish/ceiling/etc. plans, but may show in Bldg 3D views, enlarged plans and sections. Out-of-control nested modules can result in overlapping duplicate information getting created on the host file with each publish-update, so you want to understand what you are doing; screwups soon become noticeable, but changing file structures, layer combos, etc., in multi-file projects is not pretty so whenever possible it is best to think things through first.
9 - You don't want to insert stories in module-publishing files (because the host file will bring in the information contained in what it internally identifies as coming from say AC Story 4 of Bldg02.pln); the moment a story gets inserted in Bldg02.pln under story 4, the host file will be showing the zero elements in the empty story 4 of the module file for what has now become story 5) . If you absolutely need to, you will need to recreate module publishing views, modules, and place again, and/or redirect links from the host file.

[Norbert Pinter]

Thanks for the the suggestions and especially the detailed description from you Ignacio!
It looks like a very neat workflow and I will definitely use this method. Thanks again!

[Ignacio Azpiazu]

Just realised I forgot to mention, at the start:

1.1- In Bldg files, keep the file origin from Site —so that at any point in the process you can move elements from Site file to Bldg file and back by just copy-pasting and some elevate or vertical dragging in the 3D window, no x,y repositioning needed.
So that building files are modeled as if the Site didn't exist in terms of story setup, but Bldg file modeling does start off boundary-geometry lines defined in the Site file. Because these boundary and geometry lines/volumes will also change during the design process, it makes sense to publish them as modules from Site, and bring them with no x-y repositioning into the Bldg files (placed on its own Site Geometry MOD layer if you intend to be publishing with nested modules, so as to turn that off in the publishing view and avoid getting the geometry elements published back as duplicates into the Site file). If a new building needs to move 20 cm to the right, it is the elements in the Bldg file that move, not the modules placed onto the Site file (which should never move in x,y). When boundary or design geometry changes, these geometry elements will be modified only on Site, republished into the 'Site Geometry' module from which the Bldg model started off, and that module updated automatically (module update prompted at each Save) on each Bldg file.