SolidWorks PDM

[jcapriotti]

We just simply rename the files with the job number as a prefix.
Solidworks cant go looking for anything else because the name is unique.
History has shown that I can't trust Solidworks to do the right thing all the time .. so this is my Solidworkaround.

PDM systems enforce this. Outside PDM it is good practice, never have a copy with the same name.....in any CAD tool.

[Per S]

Why put file in different folders if not use PDM/PLM? I put all in one folder so never ever have same name in two files. My template files is in a separate folder and FEM, because Simulation create huge amount of files.

I run SP4 and my feeling it run great compare to SP3. But i upgrade to W10 21H1 at same time,

[jcapriotti]

Why put file in different folders if not use PDM/PLM? I put all in one folder so never ever have same name in two files. My template files is in a separate folder and FEM, because Simulation create huge amount of files.

I run SP4 and my feeling it run great compare to SP3. But i upgrade to W10 21H1 at same time,

Depends on how may files you have, 100,000 files in one folder can be slow, especially on a network drive. Also we have a library of folders based on type for purchased items so they can be dragged in via the task pane Design Library.

[Bradfordzzz]

I rolled back my Solidworks to service pack 3 so that I wont get blasted with the bugs we haven't discovered yet.
Man .. 1 step forward and 5 steps back anymore with these guys.

[MJuric]

Why put file in different folders if not use PDM/PLM?

So you don't go absolutely insane? How many files do you have that you can possibly have them all in the same directory? I wish people would actually use MORE directories here. We have directories with a 1000, probably some with multiple thousands, of files in them and it makes me nuts.

[matt]

So you don't go absolutely insane? How many files do you have that you can possibly have them all in the same directory? I wish people would actually use MORE directories here. We have directories with a 1000, probably some with multiple thousands, of files in them and it makes me nuts.

If you have a search tool, the fewer directories the better. Even if you're searching manually, additional directories just mean more clicking. If you search by typing, a single directory is best. For PDM, I used to have certain rules for creating folders. I've forgotten what they were. I'll look them up because now I'm curious...

[jcapriotti]

If you have a search tool, the fewer directories the better. Even if you're searching manually, additional directories just mean more clicking. If you search by typing, a single directory is best. For PDM, I used to have certain rules for creating folders. I've forgotten what they were. I'll look them up because now I'm curious...

Here's where I'll disagree with you. There are two ways of looking for something, searching and browsing.

• Searching, I know what I'm looking for and put in the appropriate search criteria. Folders are somewhat irrelevant although could still be useful to search within a sub-folder structure to minimize search results. Also see search results along with folder paths can help make decisions on whether I got the right file.
• Browsing, I don't know exactly what I'm looking for, but I'll know it when I see it. Scanning through a single folder with 20,000 files is exhausting. Scanning "c:\Work\Treehouse Project\Customer inputs" where there may only be 50 files is so much easier.

Folder standards really help and PDM can help that with templates.

[MJuric]

If you have a search tool, the fewer directories the better. Even if you're searching manually, additional directories just mean more clicking. If you search by typing, a single directory is best. For PDM, I used to have certain rules for creating folders. I've forgotten what they were. I'll look them up because now I'm curious...

Maybe less clicking but way more typing which I think is a whole lot slower than clicking. We have part numbers that are 25-30 characters long. I can get to those part numbers in 2-3 clicks into the right subdirectories.

I think it would also prove to be difficult if you weren't sure what the part number was, IE browsing for a part number or "Something like this".

For me having Sub dirs essentially creates a natural filter.

I can see some benefit to having a single or few sub dirs. In fact you can definitely have too many sub dirs. But unless you have a whole lot of homogeneity to your part numbers I think having a single dir would be an absolute nightmare.

[matt]

I think it would also prove to be difficult if you weren't sure what the part number was, IE browsing for a part number or "Something like this".

These are the reasons you rely on search. If you don't know a part number, maybe you know a description, even a material. You must know something about it other than visual. What project is it in, does it have a parent part or assembly, does it show up on another document's where used list.... I can't imagine professionally curated data where you don't know something about a file that you're looking for.

[MJuric]

These are the reasons you rely on search. If you don't know a part number, maybe you know a description, even a material. You must know something about it other than visual. What project is it in, does it have a parent part or assembly, does it show up on another document's where used list.... I can't imagine professionally curated data where you don't know something about a file that you're looking for.

Here's an example. All of our projects are in directories. Those directories contain the project number, description of the project and customer. Our part numbers ONLY contain the project number. So I might know something is a saw and was for customer X. By simply clicking on the Saw project folder I can look for "Customer X" and know where my file is. Literally one or two clicks short of opening the file.

Typically, for me and places I've worked, directories are used to provide a "Pathway" to the parts with information that is generally easier to remember but rarely any part of the part number.

[matt]

Here's an example. All of our projects are in directories. Those directories contain the project number, description of the project and customer...

Yeah, you need a PDM system. I can't imagine working like that.

[Frederick_Law]

Been working like that forever.
Customer Name\Job Number
We're custom machine shop.
There are no cross over between customers.

[MJuric]

Yeah, you need a PDM system. I can't imagine working like that.

We have a PDM system. Pretty much every place I have ever worked is set up like that.

[MJuric]

Been working like that forever.
Customer Name\Job Number
We're custom machine shop.
There are no cross over between customers.

Even worse here. We have a custom machine shop, standard machine builds, custom machine builds, three or four product lines that are sold by part number and three or four "Re-sale" product lines. Parts that go into our standard products are run thru our machine shop which is set up as a "custom" machine shop.

Different number conventions in different departments, different sub dirs and so on. What makes complete sense for a product line is insanity for a custom built machine and so on.

[matt]

We have a PDM system. Pretty much every place I have ever worked is set up like that.

So you have search tools, you just don't use them?

[Per S]

Depends on how may files you have, 100,000 files in one folder can be slow, especially on a network drive. Also we have a library of folders based on type for purchased items so they can be dragged in via the task pane Design Library.

300 000 files according to Microsoft. I use Onedrive

[MJuric]

So you have search tools, you just don't use them?

No, I don't use them because it seems way faster to find them by browsing. Especially when you're working on "Groups" of files or related files etc.

I use various searches when it's appropriate or when I think it will be faster.

I guess, for me, it's like all things. I'm not married to one or the other approach. Search works on a single directory or hundreds. Why not set up your directory structure in such a way that it is also helpful for browsing? So if browsing or familiarity is the easiest way to find a file, use that. If searching is the easiest way to find a file, use that.

In either case a single directory is not a great approach as doing so limits you to only one approach to finding files.

[AlexLachance]

Even worse here. We have a custom machine shop, standard machine builds, custom machine builds, three or four product lines that are sold by part number and three or four "Re-sale" product lines. Parts that go into our standard products are run thru our machine shop which is set up as a "custom" machine shop.

Different number conventions in different departments, different sub dirs and so on. What makes complete sense for a product line is insanity for a custom built machine and so on.

I feel your pain. We don't have PDM, but we have CustomTools, which somewhat does a similar thing I guess.

We have standard products
Custom products
Custom projects
standard projects


What's the distinction between a project and a product? the repetitiveness of it."Standard" projects are still very custom, but they're defined as standard when the client decides to buy a multitude of that project.

[matt]

No, I don't use them because it seems way faster to find them by browsing. Especially when you're working on "Groups" of files or related files etc.

I use various searches when it's appropriate or when I think it will be faster.

I guess, for me, it's like all things. I'm not married to one or the other approach. Search works on a single directory or hundreds. Why not set up your directory structure in such a way that it is also helpful for browsing? So if browsing or familiarity is the easiest way to find a file, use that. If searching is the easiest way to find a file, use that.

In either case a single directory is not a great approach as doing so limits you to only one approach to finding files.

Sorry, I haven't been totally following the conversation. I guess I'm keyed in to a certain method for file naming, descriptions, and other meta data. In PDM, for my system, folders are used primarily to assign permissions to groups of people, such as design engineering, manufacturing engineering, purchasing, product/project management. I suppose you could do that based on other meta data. I always found folders to just be another meaningless thing to click, especially in PDM.

It really depends on the organization of your company, and who gets access to whatever you're putting in the vault. The way you do it is how I would do it if I didn't have PDM. I was working at a company that had specific lines of products, about 20 CAD users, and probably 60 people who accessed the CAD data, plus a ECO/ECN system that was routed through the PDM workflow.

[mike miller]

How did we get started talking about file structure?

C'mon maaaaaan!! We need to get back to ripping on Solidworks. We can't let this distract us from our goal.

[matt]

How did we get started talking about file structure?

C'mon maaaaaan!! We need to get back to ripping on Solidworks. We can't let this distract us from our goal.

I do everything I can to distract you guys from that topic. The result will be so much better if that energy goes toward building and sharing information. I've been using SW since 96, and I have to say, it's always the same ol' thing. I spent a lot of time tilting at that windmill and it never got me anywhere. I assume the outcome will be even worse for you guys, since you don't seem to see what's coming next.

[MJuric]

I feel your pain. We don't have PDM, but we have CustomTools, which somewhat does a similar thing I guess.

We have standard products
Custom products
Custom projects
standard projects


What's the distinction between a project and a product? the repetitiveness of it."Standard" projects are still very custom, but they're defined as standard when the client decides to buy a multitude of that project.

We have a couple product lines that we call "Standard products"....but we rarely sell standard products of those product lines. We have one line where we have brochures showing sizes and types of our "Standard Products"...but ~85% of those products that we sell are not "Standard".

We have a machine line that has "Standard machines"...and we've NEVER sold a standard machine. The only "Standard" machines that we've built are essentially display items and show pieces.

It's even worse on the re-sale side where everything follows the manufacturers naming conventions and file storage systems.

[AlexLachance]

We have a couple product lines that we call "Standard products"....but we rarely sell standard products of those product lines. We have one line where we have brochures showing sizes and types of our "Standard Products"...but ~85% of those products that we sell are not "Standard".

We have a machine line that has "Standard machines"...and we've NEVER sold a standard machine. The only "Standard" machines that we've built are essentially display items and show pieces.

It's even worse on the re-sale side where everything follows the manufacturers naming conventions and file storage systems.

Eek, at least I was able to force some sort of naming convention inside the company for both our files and files from providers.

[MJuric]

Sorry, I haven't been totally following the conversation. I guess I'm keyed in to a certain method for file naming, descriptions, and other meta data. In PDM, for my system, folders are used primarily to assign permissions to groups of people, such as design engineering, manufacturing engineering, purchasing, product/project management. I suppose you could do that based on other meta data. I always found folders to just be another meaningless thing to click, especially in PDM.

It really depends on the organization of your company, and who gets access to whatever you're putting in the vault. The way you do it is how I would do it if I didn't have PDM. I was working at a company that had specific lines of products, about 20 CAD users, and probably 60 people who accessed the CAD data, plus a ECO/ECN system that was routed through the PDM workflow.

I agree for the most part. The System should be set up by company structure and what works best. Unfortunately in our case the company is a "Medium" sized company that still operates with a lot of "Small company" carry overs from when it started 60 years ago so "Standard" is just something that doesn't seem to apply here

[Frederick_Law]

the company is a "Medium" sized company that still operates with a lot of "Small company" carry overs from when it started 60 years ago

Yeap, boss said "I build the company with pen and paper" because it took too long to do it on computer.
I guess my time is up.

[MJuric]

Eek, at least I was able to force some sort of naming convention inside the company for both our files and files from providers.

There's a reason places like MSC and Mcmaster Carr use their part number instead of the manufacturers part number....we don't do that. It's absolutely brutal sometimes and there is zero homogeneity of part numbers or in some cases even types of files.

[mike miller]

I do everything I can to distract you guys from that topic. The result will be so much better if that energy goes toward building and sharing information. I've been using SW since 96, and I have to say, it's always the same ol' thing. I spent a lot of time tilting at that windmill and it never got me anywhere. I assume the outcome will be even worse for you guys, since you don't seem to see what's coming next.

Oops, I forgot the purple text...

[Glenn Schroeder]

I do everything I can to distract you guys from that topic. The result will be so much better if that energy goes toward building and sharing information. I've been using SW since 96, and I have to say, it's always the same ol' thing. I spent a lot of time tilting at that windmill and it never got me anywhere. I assume the outcome will be even worse for you guys, since you don't seem to see what's coming next.

They see it, but don't want to accept it (to be honest I don't either, but I've resigned myself to it). It's called "Denial".

[Frederick_Law]

There's a reason places like MSC and Mcmaster Carr use their part number instead of the manufacturers part number....we don't do that. It's absolutely brutal sometimes and there is zero homogeneity of part numbers or in some cases even types of files.

One old boss want to "hide" all purchase parts with our own part number.
We have hydraulic, pneumatic, McMaster Carr and many other.
And he complain 12345-00-00-00 is too long.

[jcapriotti]

300 000 files according to Microsoft. I use Onedrive
image.png

Those are stored locally so less of a big deal on performance, especially with SSDs. For network drives, too many files in one folder can have a big impact on things like waiting for the file open dialogue. Showing custom columns will make it worse.

[jcapriotti]

I always found folders to just be another meaningless thing to click, especially in PDM.

PDM is especially affected by too many files in one folder. Once you get a few thousand, operations start to slow down. We noticed things like transitioning files, the dialogue would take 30 seconds to show in a folder with over 10,000 files.

[bnemec]

I do everything I can to distract you guys from that topic. The result will be so much better if that energy goes toward building and sharing information. I've been using SW since 96, and I have to say, it's always the same ol' thing. I spent a lot of time tilting at that windmill and it never got me anywhere. I assume the outcome will be even worse for you guys, since you don't seem to see what's coming next.

You mean The Platform? That derailed, crippled, train has been pulling into the station, backwards, for nearly a decade. We've been hearing a lot of whistle and bell but the only thing we're seeing is the blowing of steam, no usable product.

Or do you mean what's next is SW Desktop is going to leave the station one last time with no functioning replacement? Just like the forum.

Back to folder structure. Everyone knows you use smart part numbers as your file names and you put those in folders sorted by every 1000 part numbers.

[SPerman]

Have they said why they pulled the release?

[bnemec]

Have they said why they pulled the release?

yeah, it's mentioned in the other place. Sounds like opening a file with missing ref will try to fix it by creating cyclic reference?

Never trust cad to FIFY a file ref.

[matt]

PDM is especially affected by too many files in one folder. Once you get a few thousand, operations start to slow down. We noticed things like transitioning files, the dialogue would take 30 seconds to show in a folder with over 10,000 files.

That depends on a lot of things. It used to be that a Windows server wasn't a given. It also used to be that "PDM" didn't mean "The File Management Product Formerly Known As Conisio". There are other products, and "PDM" is still a general term, not necessarily a proper name for a specific product.

That used to be a problem we only had to deal with when using low end PDM where the files weren't stored directly in the database. Does what you call "PDM" not use a real database?

[bnemec]

That depends on a lot of things. It used to be that a Windows server wasn't a given. It also used to be that "PDM" didn't mean "The File Management Product Formerly Known As Conisio". There are other products, and "PDM" is still a general term, not necessarily a proper name for a specific product.

That used to be a problem we only had to deal with when using low end PDM where the files weren't stored directly in the database. Does what you call "PDM" not use a real database?

Why would anyone store files in a database? Or do you mean store the metadata(including name and location in archive server) in database and files in an archive server of some kind.

[jcapriotti]

@matt Yeah, I still prefer that they call it Conisio. SolidWorks PDM is kinda meh. Now you have "Manage" thrown in the mix which confuses it further. Why wasn't it PDM Premium......or Conisio Premium?

[matt]

Why would anyone store files in a database? Or do you mean store the metadata(including name and location in archive server) in database and files in an archive server of some kind.

No, the CAD data is in a database for some PDM products. Actually, that's also what Onshape does - that's why Onshape doesn't need PDM - because it IS PDM. Onshape stores its CAD data in a database.

As to why... there are a lot of reasons for that. Data sharing, multiple editors, searches, I'm sure there's a lot of stuff I have no idea about. If you're really interested, dig around the Onshape site.

[matt]

@matt Yeah, I still prefer that they call it Conisio. SolidWorks PDM is kinda meh. Now you have "Manage" thrown in the mix which confuses it further. Why wasn't it PDM Premium......or Conisio Premium?

Oh, Dude, you've got me very confused. I need a bit of re-education, I can see. It drives me crazy when people take generic terms and turn them into a proper name for a specific tool. It gets so confusing to talk about stuff. I'm off to the SW PDM site to try to sort out this tangle. Take too many years off, and they change all the products.

They might not have gone with the Conisio name because that product left an odd taste in the mouth for a lot of people who used it or tried it.

[jcapriotti]

@matt "Manage" is a new product that sits on top of PDM and interacts with it to make it a PLM. Not sure how good it is, wish I could get my hands on it, I'm starting to like this stuff as much as CAD.

[bnemec]

No, the CAD data is in a database for some PDM products. Actually, that's also what Onshape does - that's why Onshape doesn't need PDM - because it IS PDM. Onshape stores its CAD data in a database.

As to why... there are a lot of reasons for that. Data sharing, multiple editors, searches, I'm sure there's a lot of stuff I have no idea about. If you're really interested, dig around the Onshape site.

So the binary CAD data is not in files, it's in some datatype in the DB, such as BLOG or something? That's interesting, and perplexing.

For that to work with the "old fashioned" CAD systems that use files, the local PDM client would need to put the file together in cache from ONLY database records, not pull the file from archive server then set metadata (properties and refs) from the database like Solidworks PDM Pro does? Or am I confused on this?

[matt]

So the binary CAD data is not in files, it's in some datatype in the DB, such as BLOG or something? That's interesting, and perplexing.

For that to work with the "old fashioned" CAD systems that use files, the local PDM client would need to put the file together in cache from ONLY database records, not pull the file from archive server then set metadata (properties and refs) from the database like Solidworks PDM Pro does? Or am I confused on this?

I don't know how SolidWorks PDM works, I was assuming it puts the CAD in the DB like other sophisticated PDM products do, but that sounds like it's the wrong assumption. The defunct PDMWorks didn't do that, in fact, it just used a big text file for meta data instead of a real database, and just renamed the actual CAD files. That was the main thing it was criticized for, and the reason it was so limited to small installations. I vaguely remember Conisio doing something odd with folders, so it's entirely possible that they are storing CAD data in folders, the traditional non-PDM way. I'm pretty sure that the full-on Enovia doesn't do that.

When I worked at a reseller ~2002 we auditioned Conisio, and I remember we chose to not carry it because of the sloppy way it dealt with the CAD file data. SmarTeam used a real db for all the data. Databases can handle a huge amount of data, especially since a lot of them were on Linux or Netware servers, not subject to Windows limitations.

[bnemec]

I don't know how SolidWorks PDM works, I was assuming it puts the CAD in the DB like other sophisticated PDM products do, but that sounds like it's the wrong assumption. The defunct PDMWorks didn't do that, in fact, it just used a big text file for meta data instead of a real database, and just renamed the actual CAD files. That was the main thing it was criticized for, and the reason it was so limited to small installations. I vaguely remember Conisio doing something odd with folders, so it's entirely possible that they are storing CAD data in folders, the traditional non-PDM way. I'm pretty sure that the full-on Enovia doesn't do that.

When I worked at a reseller ~2002 we auditioned Conisio, and I remember we chose to not carry it because of the sloppy way it dealt with the CAD file data. SmarTeam used a real db for all the data. Databases can handle a huge amount of data, especially since a lot of them were on Linux or Netware servers, not subject to Windows limitations.

My lay understanding of SW PDM Pro is that all the metadata and file refs and other stuff are stored in the SQL database, the files (all of the different versions) themselves are stored, usually on a different server, in archives. So the binary data that defines the model, assembly, or drawing is not stored in the DB. On the archive server there are in 16 folders named 0-F that contain subfolders with the versions of Vault files in those. The subfolders and file names use some naming scheme that I don't know but it doesn't matter because the archive server service handles that storing/naming/retrieving and uses the DB to keep track of the full path for each version of each file in the archives. The DB also keeps track of what folder(s) the file is in on the clients.

[Diaval]

I don't know how SolidWorks PDM works, I was assuming it puts the CAD in the DB like other sophisticated PDM products do, but that sounds like it's the wrong assumption. The defunct PDMWorks didn't do that, in fact, it just used a big text file for meta data instead of a real database, and just renamed the actual CAD files. That was the main thing it was criticized for, and the reason it was so limited to small installations. I vaguely remember Conisio doing something odd with folders, so it's entirely possible that they are storing CAD data in folders, the traditional non-PDM way. I'm pretty sure that the full-on Enovia doesn't do that.

When I worked at a reseller ~2002 we auditioned Conisio, and I remember we chose to not carry it because of the sloppy way it dealt with the CAD file data. SmarTeam used a real db for all the data. Databases can handle a huge amount of data, especially since a lot of them were on Linux or Netware servers, not subject to Windows limitations.

SWPDM uses a SQL Server back end for the vault database and stores the physical versions of the file on the archive server. Each client has a vault view location integrated with Windows File Explorer that is used as the local cache for working on files locally.

All file data including metadata, reference structures, BOMs, file locations, file versions, file status, replication status (for replicated vaults), etc is all stored in the vault database.

[Glenn Schroeder]

Have I said how happy I am that all our files are saved in File Explorer, with no PDM (generic or company name)?

[jcapriotti]

On the archive server there are in 16 folders named 0-F that contain subfolders with the versions of Vault files in those.

Files on the archive are stored in those 16 folders (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). They represent the last digit in the document ID (Documents table) converted to hexadecimal.

So document id = '113579' converts to '0001BBAB', which is the folder it's found in under the main folder 'B'. All files inside are the versions and they are renamed to the version number. The DB knows where they are based on the DocID and downloads the file to the user's cache in the stored folder location and renames it back to its original filename.

Here's a site to do the conversion:
https://www.binaryhexconverter.com/deci ... -converter

I think I know way more about this than is healthy

[matt]

SWPDM uses a SQL Server back end for the vault database and stores the physical versions of the file on the archive server.

"Archive server" meaning just straight CAD files? Are they at least renamed? Do users have a backdoor to access files on the "archive server"? This is marginally better than PDMWorks, but only by a little.

So what is real PDM in SW land these days? Enovia? SmarTeam?

[bnemec]

"Archive server" meaning just straight CAD files? Are they at least renamed? Do users have a backdoor to access files on the "archive server"? This is marginally better than PDMWorks, but only by a little.

So what is real PDM in SW land these days? Enovia? SmarTeam?

Not just CAD files, every file that is in the vault goes on the archive server, PDM Stores any kind of file. It handles some better than others.

The file versions are renamed into some cryptic scheme. So if there's file A.sldprt in the users' vault view and it has 8 unique versions, then there will be 8 files in the archive server in some folder by some filename.

Only admins should have access to the archive server, they are not network shares. So no users cannot get to the archives. There is a tool for admins to use to find the archive file for a specific version of a specific file in the vault, or admin could find it in the DB tables manually.

I don't know what Enovia is, I think it's a cloud based PLM or ERP or some partial implementation of a bunch of acronyms. I think of it as a cloud based TeamCenter or Windchill, but someone can correct me on that.

Never heard of SmarTeam.

[Diaval]

The file versions are renamed into some cryptic scheme. So if there's file A.sldprt in the users' vault view and it has 8 unique versions, then there will be 8 files in the archive server in some folder by some filename.

If a file has 8 versions, there may not be 8 physical copies of that file depending on which versions created a new physical version vs just updated metadata. To try to save on disk space, SWPDM does not create a new physical archive for a version that did not change the physical file. The archive also includes an index xml file that holds additional information about the files like which versions of the file uses which physical archive of the file.

For example, if you have a text file in the vault at version 2, then you check out the file and just update the data card for a variable that is not mapped to update in the physical file, SWPDM will create version 3 of the file on check in to store the new metadata, but the index file on the archive server will point to physical version 2 as the physical copy to use when a user requests version 3 of the file since the physical file of version 2 and 3 are identical.

Only admins should have access to the archive server, they are not network shares. So no users cannot get to the archives. There is a tool for admins to use to find the archive file for a specific version of a specific file in the vault, or admin could find it in the DB tables manually.

Access to the archive server should be treated just like any other sensitive server on the network. Physical access and remote access should be restricted to administrators who can be trusted. Basic users should not have any access to the archive server.

[bnemec]

Files on the archive are stored in those 16 folders (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). They represent the last digit in the document ID (Documents table) converted to hexadecimal.

So document id = '113579' converts to '0001BBAB', which is the folder it's found in under the main folder 'B'. All files inside are the versions and they are renamed to the version number. The DB knows where they are based on the DocID and downloads the file to the user's cache in the stored folder location and renames it back to its original filename.

Here's a site to do the conversion:
https://www.binaryhexconverter.com/deci ... -converter

I think I know way more about this than is healthy

I did not know that it was the last hex digit in the docID that determined which folder they went into. I did notice that they were not evenly loaded (disk space), this would explain why.