2 Replies Latest reply on Apr 8, 2010 4:19 PM by Fortino Lopez

    Solidworks Simulation Spending Most of Its Time with I/O

    David Maxham

      I've been running a random vibration model that has about 25,000 elements.  The model represents a fairly complicated electronics assembly (200 mm X 100 mm X 100mm )where I need to analyze the overall sheet-metal structure, the internal structure and about 8 printed-circuit boards - hence the reason for 25,000 elements.  I've already started with as coarse as possible of a mesh and have used mesh refinement sparingly but where needed.  The random-vibration environment is per MIL-STD 810 which encompasses the frequency range of 0 to 2000 Hz. 


      The issue that I'd like to discuss is how to minimize the run-times for the solver.  I first run the frequency analysis, which is the pre-cursor to the random vibration.  This doesn't take long - maybe 20 minutes or so.   The exact number of natural frequencies that is identified by the solver depends on the depth of my analysis at the particular time but there are usually 150 to 250 resonant frequencies.   When I then run the random-vibration solver, the solution can take over 20 hours to solve. 


      The computer I use has 4 processors and they each appear to be running at about 30 percent max.  Most of the time they're only running at a few percent.  I also have over 3 GB RAM (with the 3GB switched turned on), but except for the frequency portion, the RAM being used during the random-vibration solver is very small, about 10 MB or so.


      I think the reason for the very long solution times is due to I/O.  That is, with the iterative solver, at least the way it's configured, the solver needs to write out to the hard disk tiny bits of information over and over again as it iterates towards a solution.  You can see the I/O light flicker away as the data is being written/(read?) between the hard drive and the processors.


      Does what I write above make any sense?  I already have a very fast hard drive (Raptor 12,000 rpm) so what I think I need to do is get a RAM-based hard drive.  Has anyone tried using one in a case like this?

        • Re: Solidworks Simulation Spending Most of Its Time with I/O
          Fortino Lopez

          Although I haven't run vibration studies, I think I understand what you are saying. Some of the studies I've run have included 100,000+ elements and, yes, there is a lot of I/O to the hard drive. Our workstation uses an overclocked i7 with 12 GB of RAM, so I'm sure the bottleneck is the 7200rpm disk. It sounds like SSDs will alleviate, or at least lessen, both of our excessive run times. As for reviews of using SSDs with Simulation, I'm also looking for those.

          • Re: Solidworks Simulation Spending Most of Its Time with I/O
            Fortino Lopez

            After running some preliminary comparisons, I'm afraid I have bad news and good news regarding disk I/O use during Simulation solves.


            We swapped out our HDD for a RAID 0 setup using 4 SDDs via Intel's ICH10R onboard controller on a Win7 x64 box. The OCZ SSDs are spec'd for max Read/Write of 240MB/s & 100MB/s. Using AS SSD Benchmark, the array got rated for a max 602MB/s Read & 426MB/s sustained Write; pretty impressive compared to the 7200RPM write speed of 85MB/s. However, the access times were far more important since the HDD was typically in the 20-30ms range during Simulation runs, as reported by Win7's Resource Monitor. By comparison, the SSD array hit a max access time of 2ms during 300MB/s writes. Although we had doubts as to what exactly goes on during Simulation runs, by observing the Resource Monitor we found that over 90% of I/O during Simulation solves involve writing to the SW file locations. Hence, if the SW part/assembly files are located on a HDD, the advantage of having an SSD boot drive will dimish. Luckily, we created two Volumes from the SSD array, one for OS/apps and another for storage.


            So here are the results thus far from linear static studies using both parts and assemblies containing sub-assemblies. The solve time decreased by a range of 5-10%, as alluded to by the  access times. Admittedly, these aren't the performance gains we expected, but workstation performance gains are rarely linear. The good news is that the speed increase is felt during daily modeling, from opening sub-assemblies/parts to rebuilds to smaller simulation runs.


            Should new developments arise, I'll be sure to report back. Hope this info provides another perspective for those contemplating making the jump to SSDs.