Unwanted Master GDL in the libraries

[agroni]

Hi everyone,

for some years now, we have been battling some unwanted Master GLD Libraries in our Teamwork projects. I have recently found out, that other offices are facing the same occurrence.

Let me explain what is happening...

We start the project with a clean template, where only our standard libraries are available. During the project development, more or less after 1-2 moths, these libraries located in some strange folders start appearing. 

or here

You will probably think that is it from copying elements from other files. I can guarantee that this is not the case.

We have also tried the option of cleaning all related teamwork files. Nonetheless, the libraries appear after some weeks or months again. Because we don't receive error messages of missing libraries (after deleting them), this means that these libraries are not in use. We started to notice this problem already in Archicad 24. We are getting these master GDLs:

MASTER_GDL_ArchiCAD_Library.gdl

MASTER_GDLVelux81de_DB.gdl

ArchiCAD_Library_Master.gdl

Following my observations, I can conclude that the amount of those libraries might have a slight impact on performance. Still, we want to have super clean teamwork files, therefore it is bothering me a lot.

Does anyone have a similar case?

Why do they appear?

Did you manage to solve it?

I am very thankful for any input...

thanx

[furtonb]

At least you can create a folder for them and put everything there that was generated. 🙂

I used to care about this, I gave up - there are much more important things than to spend half a day every second day to clean the mess someone caused by copy-pasting something from a previous project. Result? 63736 unnecessary surfaces, fills, etc. making consistency hard to reach.

Revoking all rights (for BIMcloud projects) from everyone is a “no go” option for me, I don’t wish to become necessary for every attribute-related question or task. -.-

Have you guys read Graeber’s **beep** jobs? I cannot recommend it enough, I had found it to describe the current state of BIM management strikingly too. 

[Lucian Laculeanu]

My observations during battling these Virus-like elements for years:

- They are randomly attaching to existing attributes.

- Copying elements between projects does help in spreading them out. This is still the biggest spread factor. I like to give people the benefit of the doubt, but there is a higher probability for people not to recognize when they did this move than to admit they did it... So.. "nobody is copying stuff from other places", meaning "no one is trying shortcuts" it is not fully believable in our field.

- Having an "infected" file open while working in a clean one makes this thing jump? I  have listed this only once in my activity as plausible, but I still think that in the hurry of the production process, the person executed a series of rushed shortcuts that helped into something being transferred. That is hard to trace since everyone has its own shortcut map.

I don't want to "jinx" my limited success...but here are some actions I took and it works until that "trust element" is being broken:

- ALL attributes are mapped and all indexes are known. No new attribute is introduced without BIM management vetting. It is easier to pinpoint and delete attributes that may make their way in without your consent.

- No copy paste, unless from vetted source.

- Before Release or Send/receive always check library, and the main target attributes - fills and surfaces. This was hard but is catching on. Regardless of the team member, the user introducing them will be able to see them underlined or green in the case of the library.

- BIM manager is always browsing active projects. (dare to say, acting on suspicions... sad but true...)

- No hot-link is attached unless "clean"

- Limit external links in all projects.

I've attached here a pic of one of the projects that was in a terrible state.  This was part of the assessment process:

In this one I've observed a tendency of the "virus" to re-appear. I chose to trust the users and on a hunch, believing that it could be possible for it to attach itself to one of the "custom attributes", I went for a cleanup that presumed reducing all attributes to sandbox and re-introducing the custom ones after filtering them through a "Sandbox new file" (import XML in and export new one form there). This worked fine until someone copy/pasted.

I gave up then, but now I am trying to come up with a protocol for vetting all archived projects and one to reduce the need of referring to any of them.

I think it is just an us working like crazy thing.

The shrugging of shoulders will continue for some un-numbered years. I hope I am proved wrong on this, but trust always only bit me in the... end.

  

[Patrick M]

here's a gem. pollution is in the modules. only way to clean it up is to purge all modules, clean up the library and surfaces, build new modules, place new modules (hopefully, but not likely) in the original position.
If we can't get a fix to keep master_gdl.gsm out of the libraries, can we at least have a way to clean up module libraries without purging and rebuilding the whole thing? This particular file has 6 modules, all carry the pollution. It's going to take me all afternoon to clean this up. and since I have to do it when no one else is in the project (so I can reserve all), it's going to actually be an overnight or weekend project. Archicad is basically forcing me to work nights and weekends because of this bS.

[Patrick M]

BTW, I'm never going to NOT respond to this thread every time it gets a hit or I get another polluted file until we get a solution that works, not just another work-around or workflow specific way to 'prevent' this.

[Patrick M]

the list of ways to avoid pollution mean that project teams are fixated on avoiding pollution, instead of designing and documenting.
I've seen 2 results of pressuring teams to keep pllution down by all means necessary:

1. they don't fully understand the myriad of causes/triggers, and miss a crucial step occasionally 

2. they don't understand the pollution being described and avoid any document coordination (IFC/DWG may bring in layers or surfaces, so they equate that to being "bad")

I've been struggling with this issue for well over 10 years now, and trying to teach project teams to avoid this is like trying to convince them that learning a little GDL is worth it. It either stresses them out, or they can't be bothered to understand the issue. I agree, avoiding copy/paste is instrumental in keeping this clean. But c/p is definitely not the only trigger for pollution. The solution needs to be from a development side, not an end user workflow side.

In the mean time, a not too inconsiderable amount of my work day will continue to be spent scouring the dozens of t/w files I'm managing on several BIM servers to try to keep it weeded out as best as possible (which is a very uphill battle, as you know).

[agroni]

Thank you all for your replies. It is sad to hear, that we are all dealing with the same problem.

In the beginning I thought it was our internal fault, that these "bugs" were appearing, because some bear names of familiar projects or instances. 

I think, it is time that Graphisoft took the case more seriously and pushed it into the roadmap. Actually, it is not a part of a roadmap, but repairing the mistake. Anyone from Budapest would like to share some thoughts?

[Patrick M]

just giving this one more bump; 
this week I found a project that consists of 6 intertwined teamwork files, each containing 3-8 hotlink modules (as well as various consultants ifc modules). It's such a big project, I can only clean it up nights and weekends so as to not have the team trip over my reservations. I'm also stuck with the task of untangling and replacing cleaned modules in the exact position, with limited direct knowledge of design intent.
if this were a simple "delete the master_GDL and offending attributes", it could be done by the team, or I could do it with no worry of adverse impact on the project and documents. But since it requires scrubbing through the libraries to locate the problem, most project teams either can not do the clean up reliably, or do not have the hours in teh project scope to dedicate to the task.

Either cleaning HLM libraries needs to be easier, or this pollution issue needs to just not be allowed to happen from now on.

[davidzsibrita]

I am currently testing a possible workaround. Maybe someone has already tried it and can provide feedback, or does anyone see a potential problem that I don't see yet?

I am currently gathering all the known MasterGDL from our office into a linked library. 

The experience so far is that when this library is linked to a project, no new elements end up in the embedded library after copying.

The attributes are initially included in the project. However, they would be copied in over time anyway.

The advantage is that if you copy something from this file later, nothing gets transferred because nothing is in the embedded library. Copy/Paste is significantly faster.

The idea is that after a few years, no project will have the MasterGDL in the embedded library, and this linked MasterGDL library can be removed from the project templates.

Still, you need to check afterwards to ensure it doesn't pop up somewhere again.

[Aaron Bourgoin]

The Kling Loading Dock Library Objects seem to place a macro that queried the list of surfaces and if they weren't there added 192 RAL Colours. This continues to haunt the office via the copy/paste virus like feature that GS refuses to remove.

[Darkas]

Hello, 

I have the same problem.
The worst part about manually deleting libraries is that I have to reserve each library individually and then delete it.

Do you have any tricks for this?