Large Assemblies

[SoledWorker]

Our company is evaluating 3D_CAD Software for machine design, and I'd like to get a feel for the size of model (number of parts) that people are building with SWX.

Please don't turn this thread into a "Software X vs Software Y" discussion, the main question is:

In the models you currently building, how many parts do you have?

If you like to type, some other questions are:
For large assemblies, what kind of performance do you get with rebuilds, saves, editing of parts, etc? Do you use "light" parts?

 

[SBaugh]

In the models you currently building, how many parts do you have?

Mine vary from just a few parts to around 100 parts. There are a lot of people I know, that are building assemblies with more than 500+ different parts.

If you like to type, some other questions are:
For large assemblies, what kind of performance do you get with rebuilds, saves, editing of parts, etc? Do you use "lite" parts?

As for performance when assembling this can vary due to in-contexting parts.

An in-context feature has an external reference to the geometry of another component; the in-context feature changes automatically if the geometry of the referenced model or feature changes.

When a user in-contexts his parts the performance goes down. The user may only be using a few parts in the assembly but this still depends on how deep he/she has in-contexted the parts.

But for just a regular non-in-contexted assembly I would say SW works great and runs at a good pace.

May I ask what kind of hardware you plan to run SW on if you buy it? This can be an issue to performance also.

I hope that helps, Scott Baugh, CSWP
George Koch Sons,LLC
Evansville, IN 47714
sjb@kochllc.com

 

[SoledWorker]

No matter what we get software-wise, we will get video cards recommended by the software developer, 1Gig Ram, fast Pentium processors, and Win2000.

 

[BBJT]

Hello,
We currently have subassemblies that are 1700 to 2000 components in size. Probably 700 of those components are unique, meaning inserted only once. Again these are subassemblies. We have had SolidWorks in to take a look at our network and they agreed it was a descent set up. We are currently working with them to solve some speed issues on the network. Loading these assemblies on the network full weight takes anywhere between 10 to 20 minutes, depending on whether or not it is jumping form one server to another for the info. In lightweight it knocks the time down to 5 to 7 mins.
On the hard drive we load the assembly in a minute and a half. Networks become a very big issue with any package. It comes down to type of network (NT, Novel, etc.), switches, line speed etc. We are currently looking at a central location for our SolidWorks files on an application specific server.

Take it from a former SolidWorks re-seller, do not take the demo jocks word for how fast they can load assemblies. Make them show you in your own environment.

I think SolidWorks overall is an excellent product and will lead the 3D world.
BBJT CSWP

 

[DeanBanks]

BBJT,

Can you provide some details about your current network configuration, and what suggestions your SW consultants have given?

We have similar performance problems, and I am eager to try anything to appease our SW design team. Our current network configuration is switched 100Base-TX, full duplex from server to switch and switch to workstation. We run Win2k Server and a mix of Win2k and NT4 workstations.

In some basic throughput tests, I've timed the copying of large single files and large directories using Windows Explorer, and get numbers in the 3-7MB/sec, as might be expected on this network.

When loading large assemblies in SW, things slow to a crawl. I'm speculating that SW can multitask the opening of files from a local drive, but has some limitation when working with network files. As far as I can tell, this is a SW-specific issue, and it not directly related to network bandwidth.

We're installing a dual Xeon 1.7GHz workstation tomorrow, so I will also have a chance to benchmark the impact that processor speed has on file load time (as it looks like SW does some amount of computation between each file..)

Clearly, we're asking more from SW that it was designed for, but where is the fun if you don't push your tools?

-Dean

 

[BBJT]

Our current network configuration is switched 100Base-TX, full duplex from server to switch also. We however are running on NT Server but will be forced to go to 2000 server in the near future. I hope 2000 server is not the issue or we will be in the same boat soon. This kind of scares me because if some if the performance issues that we are having with a lot of our applications in Windows2000 operating systems.

My area is one of a few that has a 100mg line from my box to the server. It really makes a big difference. Most of our locations have 10mg lines from their box to the server. The above assemblies (2000 comp) which takes me five minutes to open takes 16 mins to open on a 10mg line.

A couple of questions I have are...

1.) What version of SolidWorks are you running? We are running 2000 SP10.

2.) Are you running stand alone or thin or thick client?
We are running thin client meaning that the whole SolidWorks application is installed on a server not on the local machines.

Some things to take into consideration.

1.) We have centralized our SolidWorks files(prt.asm,drw) onto one server. This seemed to speed things up a quite a bit.

2.) USE LIGHTWEIGHTS. Set the option to indicate if lightweights are out of date.

3.) Simplified models and configurations. This one I will be presenting to our users in the near future. Our main assemblies consist of 4 levels of subassemblies. If you are showing hardware in a lower level assembly don't show it again in the upper level assembly. In the upper level assemblies there usually is no reason for showing great detail.

4.) The more memory the better. If you start swapping because you ran out of memory you might as well take a lunch. We are running 1G Compaq with 512m of ram which is the most these boxes allow. Memory is cheap MAX it out.
The users did not see a big difference going from an 866 to a 1G. Memory seemed the key.

5.) Virtual memory settings help with memory problems also. I recommend to our users 2x for the min and 4x for the max. Example: My computer has 512M of Ram. My minimum setting for the virtual memory is 1024 and the Maximum is set to 2084.
BBJT CSWP

 

[DeanBanks]

We're running SW2000 SP13.

We run stand alone installations with a single license server. The rationale was to maximize available bandwidth for data, leaving the application local. Understandably, this becomes less feasible as the number of clients (that need to have monthly Service Packs applied) increases.

It seems like workstation processor performance has a large effect on load times--SWX is doing something processor-intensive during the load. Having a fast CPU also helps with the rebuild that may or may not be forced after loading.

Be careful with your swap file settings--ideally the min. and max. settings should be the same, creating a fixed size file. If you have different min/max settings, your swapfile can get fragmented, creating a big performance hit as your drive goes hunting for all of those little fragments...

We run a minimum of 1GB of RAM on all of our workstations. I agree that it is a great cost/performance trade. It's also much easier than upgrading/adding CPUs.

In researching the load speed issue on the SWX website, I found that the graphic settings (Tools -> Options -> Document Properties -> Image Quality) not only have an impact on display speed, but file size as well. Setting these to lower quality levels will reduce the filesize, presumably improving load speeds. Note that this is part/assembly specific and cannot be set for the overall SWX installation.

-Dean