Client locked features

[aruckerY7D6L]

Hello all,

Today, I have a fun one. How does one lighten a project without the ability to add/modify/delete (purge unused) families?

  One of our clients has stringent security measures and some things have been blocked. One such feature is the ability to add/modify/delete families; if something needs to be done, a formal request would need to be sent, even for 2D items like text and tags. The process turnaround can take a few minutes to a few days, depending on factors not readily known to me. Another security measure is we have to VPN/remote into another computer running Windows Server 2012 R2, and we are also required to use Revit 2019 without MEP items.

The files are crashing more often or take 20+ minutes to sync. While the main file is about 100MB, as I understand, this shouldn't push Revit to the edge. As far as I can tell, we have all of the Microsoft and Autodesk updates done, and the remote systems meet the requirements under "Performance: Large, complex models" mentioned here [https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/System-requirement... 

I do not want to, nor am I fishing, for a way to undermine the client's measures. What are other ways to make our files run more smoothly that can be done on our end?

[syman2000]

This is pretty counterproductive. Any reason why they want to lock things down? Also forcing you to work in 2019 is pretty bizarre. How do you charge the project? Is it by hourly or is there a certain deadline you have to meet? If this hinders your project deadline, then you should notify your client.

[RLY_15]

20+ minute sync time that is disproportionate to file size might suggest a file integrity issue, but it could just as easily be something weird like non-rectangular crop regions, embedded PDFs/CAD links, or any number of things that have been patched since v2019.

Is it possible within the limitations of your contract to export all project-associated families out to a sandbox for isolated testing? A perfect scenario would be that it's just one family file causing all of this. Removing the server/VPN aspect from the equation at least gives you an expedited testing method for one potential source.

Even if it's an issue of proprietary information, maybe at least be given a sandbox file within their VPN/remote structure so that the testing is fully transparent and contained on their platform?

[aruckerY7D6L]

The client has made 3D families with specific parameters that feed to and from reports/spreadsheets. At the beginning of the project, we were told not to alter or create new 3D families. If we needed new equipment, then we would have to request it to be done by the BIM team. I assume this was to avoid parameter misspellings or otherwise negatively affecting the reports. This was later changed, and all families were locked from getting altered. I am not sure how it was done.

As for version 2019, I received no reasoning for this, but the project has been in design for some time now. It might be this was done to avoid taking the time to update the files-maybe, Revit 2019 may be what many contractors already had. I am not part of the department that handles the contracts/finances, so I am unsure how the billing goes. 

These concerns and others have been brought up to the client by other contractors as well.

To add to the dynamic, this is the first job for our company using Revit. I would always point out how things could be better if we switched from ACAD, but that was presuming we would use MEP items we managed ourselves.

[aruckerY7D6L]

When you say sandbox, would a detached file fit that?

It has been made clear that no 3D content is to leave their system, only 2D PDFs can be pulled and that is another process in itself. I have run Audit on the central model and purged out what I can, but if it's like AutoCAD where you can have nested families to infinity, I am not sure how to pull it off.

[RLY_15 · Accepted solution]

Preferably it would be a brand new project template, with the project families being loaded into the new environment one at a time. A detached file that is stripped down of modelled elements might work, or it may inherit the original problems altogether, in which case you won't know what's causing the issue unless you test by omission instead of by inclusion.

One simple check that you can try is to simply examine the families with the largest file sizes. Typically speaking, family files don't become much more than a megabyte or two unless A)there's nested families or B)there's exceedingly complex geometry/constraints. Issues in small families tend to produce small errors, issues in big families tend to produce big errors.

Our workflow for a corrupted project file is usually to load the families in to a new environment from largest to smallest one at a time, making sure to flex them, adjust parameters, and if MEP play with their connectors. And just observe if errors start to generate or performance starts to suffer from regenerations or recalculations. If nothing is problematic in the new environment, we start doing the same with linked files (and sometimes their individual families as well), until something breaks.

If nothing breaks after all that...I call IT 🙃

[Lachlan-JWP]

@aruckerY7D6Lwhat's your role here? Are you engaged to diagnose and repair their system?

[aruckerY7D6L]

Our role is to take the design duct and turn it into how it will be fabricated - replace volume dampers with correctly sized ones with access zones, break the duct from 100ft into individual parts with connections, and do clash detection along the way. Finally, we prepare shop drawings and cut sheets for installation/fabrication. This post is regarding the file becoming increasingly bogged down, and I usually address issues with how things look or, to an extent, work.

[aruckerY7D6L]

Thank you. One of the issues is that the issue seems to be cumulative; it has become increasingly bogged down over time. I did export all of the families and have found one 2D family that, for some reason, is >5MB. Oddly, this is nested into the title block, only 1800kb.

Your response has given me a direction forward. I will have to play with the large family to make it smaller and have them reloaded into the model. Hopefully, this will remove some issues or eliminate this as a possible cause.

[RSomppi]

---

@aruckerY7D6L wrote:

Our role is to take the design duct and turn it into how it will be fabricated

---

This is usually done in a separate model from the design model. In an ideal world, you could simply convert the system duct to fabrication duct but this won't work if the design model didn't take this into consideration. Your results will vary. Some places don't even try to do the conversion and just use the design model as a guide to trace over.

[aruckerY7D6L]

Correct, it would be easier that way, and how we have worked in the past. This client, however, has a unique workflow that we are still not used to. Also, as families are created and controlled by others, we have been restricted to these and not allowed to convert to fabrication. These and other matters have made my company's first job using Revit as the primary modeling program challenging beyond the expected learning curve of a new program.

[RSomppi]

Not a good way to start. It might be worth reviewing the terms of the contract deliverables. I’ve done a couple oddball projects like this and the guidelines aren’t usually followed exactly by the team dictating them. Beyond that maybe begging for mercy with an honest explanation might help. Lastly, getting out of the contract early will be less expensive than later.