Total Occurrences, practical limit?

[mslosar]

I'm curious if there's a practical limit of Total Occurrences you can work with in Inventor?

Our machines these days are maybe 2 year old laptops, 14 cores (8/6), with 64GB RAM and Quadro A4000.

I've got people doing assemblies of 380 unique files and 256,000 total occurrences.  On my machine, i can open up a sub assembly of 120 parts and 3-4k total occurrences with no real issues. The overall at 256k takes over 15 minutes to open and then i can't really do anything with it afterwards as takes forever to redraw the screen.  I'm working on a substitution scheme to address that.  This seems to be causing issues with Vault Check in as well. But, generally i'm curious if there's a practical limit for Total Occurrences that people have seen.

Curious as to thoughts.

[CGBenner]

@mslosar Are any of these parts carrying complex patterns, for example a spacer full of holes, or something like that?  Complex patterns usually take more resources to compute one at a time, so if there are hundreds of parts with patterns like that, it could explain what you're seeing.  I suppose any complex geometry that needs calc time, repeated many time, could also cause lags.

[mslosar]

From what i could gather, most of the quantity is hardware. I don't know what any of those patterns are overly excessive....maybe 50ish at most?  There are patterns of sketches, as in a circle drawn on top of a plate to represent where something will be cut and there are some good sized patterns there.

The massive file in question had 6 different sub assemblies in it with varying number of them (6 of this, 2 of that). I could open each sub assembly and had no issues there, only in the giant one.  I have other models of my own with 100-200 holes in a rolled plate - and that can be slow, no doubt. This isn't that.

What I did as a test was to make a simplify model of each sub assembly and have that be a model state.  I then opened the giant file and set the representation to use the simplified versions.  The assembly that took 15ish minutes to open, took 20ish seconds to open.  The vault check in that was taking upwards of 20-40 minutes, took me 3 minutes. Amazing what happens when total occurrences is reduced from 256k to 100 (no k) 🙂

I was curious if there's sort of a limit that if you're using 64gb of RAM if you shouldn't really exceed x total occurrences.  I'm thinking even if i went to 128gb it likely wouldn't make a difference as tracking 256k objects in a view is going to hammer most, if not all, processors out there.  I'm hoping there's some backing information here so i can explain to the execs what the nature of the issue truly is.  I kind of want to tell them hardware of the day really isn't going to handle that many objects well and that the application isn't really set up for that large a data set without going to things like simplification, etc. Can I sell that explanation? sure, but I'd prefer to sell the truth. 

[johnsonshiue]

Hi Mike,

For a given amount of RAM, there should be a theoretical limit. However, it also depends on the geometric and structural complexity. It is hard to comment. When you encounter slow open, how much RAM was used? Could Windows start using SWAP space?

Many thanks!

[mslosar]

It's hard to say using this machine as the reference. I can say it took 15+ to open, but CPU seemed to never drop below 50-60% even after that seemingly completed. I could access commands in Inventor, etc. But as noted, if i tried to move the view ever so slightly, everything pegged up to 100% or so for a few minutes before completing. I did not see any complex modeling in the sub assemblies. The most complicated things would be a couple sheet metal bends and some bolt holes.

I would expect if it the complex modeling was at issue, a sub with 4000 occurrences would show some effects of it, but other than taking 30-45 seconds to open that file, everything seemed fine. I'm not really anxious to experiment with the unsimplified large assembly for obvious reasons, I suppose i can maybe do a more in depth look on the sub assembly for any complex factors, but it seems like the total number was the killer not the complexity.

[johnsonshiue]

Hi Mike,

The behavior you describe sounds more like the machine is low on system RAM or low on GPU RAM. How much system RAM and GPU RAM does it have?

Many thanks!