10 Replies Latest reply on Jun 29, 2015 1:30 AM by Ned Hutchinson

    SW 2015 SP0  simulation RAM memory stack up

    Andrei Popov

      Hello all,

       

      I am using SW 2015 SP0 Premium Non-Linear Simulation and I have an issue with the RAM memory stack up.

      I am running a simulation with 452000 DOF using the new Intel Direct Sparse solver the new feature of SW2015 to use all available cores in the CPU.

      The machine I am using is:

      3DBOXX W-4920

      Intel Core i7-3960X CPU @3.30 GHz -12 cores

      RAM 32.0 GB

      Windows 7 SP1 (64-bit)

       

      The issue I have is that the simulation is building up the memory until it reaches the maximum hardware limit and SW freezes or crashes.

      I had the same issue before in SW2013 when everytime I was changing a dimension in a Scketch, the model was rebuilt and at each rebuilt the memory was stacking up until I needed to shut down SW to dump the memory and start all over again.

      I am attaching here an example of Windows Task Manager screenshot:

       

      SW forced shut down when RAM reached 30 GB to dump the memory:

      Intel Direct Sparse memory SW2015 closed.png

      SW restarted, model and simulation reloaded (total RAM 4.17 GB) but after simulation restarted, the memory buids up again after 3 iterations:

       

      Intel Direct Sparse memory SW2015 restarted.png

       

      What other options do I have except monitoring the memory stack up and force shutdown SW?

      Is there a setting in SW I am not aware of to dump the memory?

      The only setting I am aware of is in the System Options > Performance > Purge cached configuration which is checked on.

      I searched the forum for memory leaks issues and I followed the suggested fix, increased the GDI object limit in Windows from 10000 to 16384 but obviously there is not this issue, SW barely uses 1200 GDI objects as shown in this screenshot (the 3D Space pilot is using 10000 GDI objects but this is not an issue):

       

      Task Manager GDI objects.png

       

      So, what is the problem with the RAM memory stack up?

        • Re: SW 2015 SP0  simulation RAM memory stack up
          Jared Conway

          i don't understand the workflow here

           

          you're saying ram increases over long periods of using solidworks?

           

          or you're saying that ram increases after you hit run?

           

          does this problem only happen with this model?

            • Re: SW 2015 SP0  simulation RAM memory stack up
              Andrei Popov

              Hi Jared,

               

              The workflow is the following:

               

              Open Windows: RAM memory 3.5 GB

              Open Solidworks: RAM memory 4.27 GB

              Open the model: RAM memory 4.72 GB

              Open the SW Simulation add-in and non-linear study: RAM memory 4.78 GB

               

              I save the model with a different name, memory goes up to 5.15 GB and then down as previously 4.83 GB.Until now everything is fine, but as soon as I go to the model and modify something in the scketch the memory stacks up.

              It seems to me that at every rebuilt, Solidworks is calculating the new geometry and ocuppy an amount of memory space for that, which is OK.

              Here is an example of memory stack up after rebuilt, te memory raised to 8.84 GB:

               

              After the calculation is performed and the model is updated, it is not OK to keep memory ocuppied, Solidworks should dump the memory to make room for other calculations. After a couple of modifications and rebuilts in the model, the memory goes up to the ceiling and then freezes or crashes. So to avoid that I need to constantly monitor the memory stack up and to force shut down Solidworks to dump all the loaded memory .

               

              This happens in a time span of 5 or 10 minutes which is the approximate time span of the Windows Task Manager in the above picture.

              Of course it depends on the compexity of the model and the complexity of the calculations.

              In my first post the memory stack up is done by NSTAR when solving the study, but in my second post the memory stack up is done by Solidworks, so I suspect there is a bug in the memory management of Solidworks. In my opinion it happens in all models, at least I saw it in all my models, although I build them in a similar way using the circular pattern feature.

               

              I think this bug is not visible in simple models with few features. Actually in my model which is a gear wheel I have just 3 Boss-Extrudes and 3 concentric Circular Patterns, but because one of the pattern is a 600 elements array and the other two patterns 300 elements arrays, the model rebuild requires a big amount of calculations. Because the model has a large number of array elements, this also implies that my simulation mesh has a large number of DOF, anyways I have more than 200000 DOFs in all my models. But as I said after the calculations are done and the new geometry solution is found, the previous data in the memory should be dumped to be replaced with the new data. I don't understand why after each calculation the data is kept in memory and never dumped.

              Why there is not a function in Solidworks that verifies the amount of free memory in RAM and when is critically low, it saves the data on the disk, in the case this data is really necessary to be there for Solidworks calculations? Is this not a common practice in the CAE/FEA world?

            • Re: SW 2015 SP0  simulation RAM memory stack up
              Ned Hutchinson

              I have this same problem

               

              Memory build up over day while opening and closing Parts and Assems till you get up to bout 13 GB of memory then starts crashing

               

              Even after closing solidworks completely it was still up around 13GB

               

              Doesent free up until end processes of SLDWORKS.EXE

              which is still running in processes but not applications

               

              64 Bit

              16GB Ram

              Nvidia Quadro K2000