User Case: updating and publishing plans in big projects

[agroni]

Even though there are many discussion and posts about layouts and efficient workflows, I thought I’d share with you my own experience with a special topic: how to handle layouts and publishing in very big projects.

It is actually nothing that I have discovered, but the need for an efficient workflow in our office brought me to many spent hours in experimenting, consulting others and putting all possible information in one place. The reason why I took this journey is because our publishing process of over 100 plans into PDF and DWG took more than 2 hours. This is too much and is even worse since for a period of 1 hour none of the 9 team members could work in Teamwork (I will explain later why). Therefore, the experiments reduced the publishing time of the same plans down to 30min. It is still a lot but, that’s the maximum I could squeeze. This “slow” case that I am describing you here is the scenario where drawings are placed as views in the same file and updated automatically.

One of the problems with big projects, especially in construction phase, is the updating process of those plentiful drawings in layouts. Some layouts in our case have 4 drawings and some even 12. Some representing floor plans and some section or even elevations and also a combination of all mentioned. Every time you open a layout, the updating process of those specific drawings will begin. In total to update all drawings for all layouts took us around 1h. After this process, we could start publishing PDF and DWG which took another 1h. The PDF was not so painful as publishing DWG. And the reason why nobody could work for this 1h in Teamwork is because the moment someone drew something, the layout saw this as a change, hence wanting to update again, and again, and again... To publish a DWG is more delicate case then a PDF, because everything must be up to date and correct, otherwise you get errors.

For the solution I took something that I hadn’t worked for at least 10 years. The famous PMK file. This is why I am saying that I did not discover nothing new here, because the Plott Maker strategy was introduced by Graphisoft more then 10 years ago. The plotmaker was discontinued but the PMK format stayed though.
Our strategy was to publish VIEWS from the model files (since the project is big, we have 5 teamwork files) as a PMK and store them at our local server. These views will have their corresponding place in an external layout file that was dedicated only for publishing. This allows fast opening of layouts and a very fast possibility to update them. Compared to a normal updating process which took around 1min per layout, updating from PMK is a matter of 3 seconds and sometimes even milliseconds. With the help of the drawing manager you are able to update, control and correct drawings also in a matter of a few seconds. All PMKs are stored at a single folder (a pool) where these documents are going to be overwritten when the publishing time arrives, hence updated in the layout file. File size of a PMK ranges in kB with rare occasions up to 2Mb. The drawings in the layout could be left to “automatic update” since I could not see any rise in file size when switching to manual update (save in project). But for management reasons I left this option to manual, for the users to have better control when updating plans.

Another cool advantage is the change manager which also works in PMK. All changes, respectively change clouds, are saved in the PMK and correctly read and documented by the Index-Table in the Layout file. The only disadvantage of the change manager and separate layout file is the backward synchronization to the main file, which changes have been published or are closed. There are some workarounds for this (I can explain if someone is interested).

In addition, all possible auto texts and especially the ones referencing to drawings are displayed correctly. Scale of the drawing is also correct. No information is missing or displayed wrong… so far.

In the end I also tested a disaster scenario where we lose connection to our server, meaning the link between the PMK file and drawing is lost. It might look like a moment to panic, but the program is capable to reestablish the connection within a matter of seconds, hence again all drawings up to date.

I hope with this “short” resume I could explain and give some hints for those struggling with this matter. Feel free to comment or even give hints

[szab]

Hi Agron,

you told about backward synchronization to the main file, which changes have been published or are closed and that there are some workarounds for this. We are working on a large social housing project and I would be keen on your further experience about this...

Cheers
Szab from Germany

[agroni]

sab wrote:
you told about backward synchronization to the main file, which changes have been published or are closed and that there are some workarounds for this. We are working on a large social housing project and I would be keen on your further experience about this...

Hi,

The problem with Change Management ist that all changes documented in the main file, cannot be marked in the part files. In this case the program does not send a "Signal" from the main file where the LayoutBook has been closed to the part files.
Our current workaround is to mark changes in the part files; synchronize them to the main file where they are going to be closed. At this moment we immediately publish plans as PDF and in the part files all changes are going to be moved to another layer so the don't bother the users.
If you follow the steps there, it works well...

regards

[szab]

Hi Agron,

thanks for your reply, will try

[Da3dalus]

Another thing that smoothes the process of getting a deliverables out is to have a separate unmanned computer on hand. Use it to open the Teamwork Project with the Layouts, reserve them all, and use the Drawing Manager to constantly update (after setting all Drawings to Manual Update). Waiting around for a sheet to regenerate when you have real work to do is demoralizing and counterproductive.

Funny you should mention PlotMaker. This was a workflow I used to use with that program long ago, which was nice because PlotMaker did not require a license key. In your case, you will need a separate license. However, the cost for having another computer and license is probably less than the time lost waiting for updates. A good machine is $3000 (replace every 4 years or so), an AC license is $5000 + $500/year (less than $2000/year over a decade), and this should be insignificant as large projects like this should be raking in hundreds of thousands, if not millions, in profit. Just good business.

[Anonymous]

Hi,

I hope is not too late to come back to this post but I have a question regarding the PMK workflow and I would appreciate your feedback.

We have a dedicated machine exclusive for the BIMcloud. All information regarding non teamwork projets and all the publish files from temwork projets are stored in another machine. We are now starting to implement the separate file workflow for layout only with pmk's for large teamwork projets.
The question is: should we publish the pmk files into the machine where bimcloud is running or into our regular server? I am aware that both ways works but is there a clear advantage for publishing to one machine or another? Speed? file path issues? etc..?

thank you.

[Da3dalus]

Afaria,

Generally, you want to keep the servers separate. The BIMCloud server can use up a lot of resources, and this may conflict with a File Server running on the same machine. Keep your File Server on a separate machine, and create folders in your Standard Project Folders to save Published PMKs, PDFs, DWGs, IFCs, and ArchiCAD PLN/PLA archives.

Keep in mind that, if you're using Windows, your file server will require Client Access Licenses (CALs) for users to access the shares. However, the BIMCloud server does not require any such access, and can be run on a non-server-class machine (or multiple machines if you have the paid enterprise BIMCloud instead of BIMCloud Basic). You can run it on a standard Windows workstation, and just provide HTTP internet access.

One more note: if users are working remotely, they cannot access PMKs directly though the BIMCloud. You would need a separate VPN system to update these links. However, if updating is not necessary, users can work from anywhere with internet access on the ArchiCAD Teamwork files, without a VPN.

[Anonymous]

Thank you very much for the input.

[Anonymous]

I agree, the pmk method has served us well also over the years. There seems to be a point where stripping out the layout book is the way to go.
On large projects the layout book can equate to about 20-40% of the file size able to be separated from the model file. Depending on your hardware, you might trigger this at 4gb (of 'clean' work) or so but I've known 5gb files to work OK for us.
There are tricks to making single file projects work too but it takes diligence and awareness from the staff to work cleanly. This is often where you need to assess time pressure and staff skill levels.

[Anonymous]

We're using the PMK method for quite some time with a lot of success. From towers to large masterplans. Every practice will be slightly different but I suggest develop a workflow that suits your hardware, user experience and project type. You might even find using PMK's just for references and placing views for the majority of documents is OK just to take the edge off the file size and improve the speed. Having multiple files does speed up the work generally but can be a bit annoying going back and forth.
Also, take some time to learn how the back references and markers work.