8 Replies Latest reply on Sep 30, 2013 11:25 AM by Jared Conway

    Flow simulation 2012 SP5.0 batch simulation crash on x2+ simultaneous runs

    Dragos Ciordas
    Dragos Ciordas Sep 17, 2013 6:08 AM

      Hello,

       

      I have a rather big issue with Solidworks Flow Simulation, namely the fact that I am unable to run a batch analysis with 2 or more simultaneous runs. Solidworks stops responding and completely crashes whenever I try this as you can see below.

       

      vlcsnap-2013-09-16-13h16m00s171.png

       

      In detail:

      - x2, x4, x6 simultaneous batch simulation attempted, all crashing after various times

      - plain and x1 batch simulation runs without any issues

      - issue present on another similar computer as well

      - Solidworks 2012 SP5.0, Flow simulation 2012 SP5.0 build 2142

      - Windows 7 SP1 x64 machine, 2x Xeon E5-2620 CPUs, 24GB RAM, Quadro 2000 video card

      - all relevant files are saved locally (not on network)

       

      Fixes attempted:

      - disable all non-essential windows processes (such as explorer.exe)

      - disable multi-threading

      - Solidworks reinstall

      - Office (2007) repair

      - Full CPU allowance for all instances (12/24 on all of them)

       

      VAR response, suggestions attempted without success:

      "I know you are using 2012 however I was checking in SolidWorks 2013 and noticed that there is a change in behaviour.  The “Maximum simultaneous run at this computer” option from the Batch Run command is limited to 2 simultaneous runs. This change is intentional as it apparently offers the best balance of performance and flexibility.  Previously, the  option from the Batch Run command was only limited to the number of cores on the computer – hence why you can do so many.  After discussion with the guys here we also think that perhaps SolidWorks limited the number of simulations to make it more stable and make it so that everything is handled a lot better.  I appreciate you are trying to do so many at once for convenience sake but I would ask that you try 4, or, since it is the only option in 2013, 2 studies at a time and see if it completes."

       

      Windows crash log error:

      Faulting application name: sldworks.exe, version: 20.5.0.80, time stamp: 0x506ff2af

      Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e

      Exception code: 0xc0000374

      Fault offset: 0x00000000000c40f2

      Faulting process id: 0x1474

      Faulting application start time: 0x01ceb2d2a3b8bc00

      Faulting application path: C:\Program Files\SolidWorks Corp\SolidWorks\sldworks.exe

      Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

      Report Id: 360f7dde-1ec7-11e3-bc31-0015833d0a57

       

      Can anyone help me with this issue? I know x1 simulations run fine, however that only uses around 15% of the CPU and basically means 85% of the machine is wasted. We are in a rush at the moment and being able to finish the simulations quicker is critical. I do not believe this to be a Solidworks limitation as it would not make sense. Simultaneous batch runs are not complicated to implement and are a great efficiency booster so I do not understand why this would not be working. This is not a new feature either, and the lack of information on this problem makes me think this generally works for most people.

       

      Thanks,

      Dragos Ciordas

       

       


        • Re: Flow simulation 2012 SP5.0 batch simulation crash on x2+ simultaneous runs
          Jared Conway
          Jared Conway Sep 18, 2013 2:46 AM (in response to Dragos Ciordas)

          Not totally following.

           

          You have a quad core right?

           

          You're asking the software to run 6 projects/configurations at one time (simultaneously) with 4 CPU each?

           

          When you set it to only run one at a time, all of the exact same (specially the exact same) run without issue?

           

          Seems to me we are taking about a resource issue. Is it a software or hardware limitation, totally possible. But what you are asking for is really taxing and I'm not confident you would actually get better performance. If it is a software problem, your var will have to check in 2013 and likely the issue if found will be fixed in 2014. But like yor var said, things have already changed.

           

          How do we figure out be problem? Has someone else tried running your file? Ideally on a computer with the same and different hardware. Have you tried the newer versions? The issue may be resolved and with other improvements may be faster than 2012 even at 1 simultaneous run.

           

          If it is a limitation or bug, you're stuck. I'd really be looking into an efficient way to run the simulations you need to run. Have you leveraged all the appropriate simplifications...etc. and look into why only 15% of your CPU is being used when running one sim. That doesn't sound right. Looking at what studies you're running and whether they are needed is a good idea too. Could you leverage a parametric optimization for example.

           

          Something you haven't considered is that this may be a windows limitation or issue that we have no control over. This is another reason I'd suggest looking at what you are doing vs probing the software.

           

          Another thing to consider. You could split the part configurations into multiple files and try running batch on multiple files or multiple batches multiple sessions of solidworks. Done both in a bind before.

            • Re: Flow simulation 2012 SP5.0 batch simulation crash on x2+ simultaneous runs
              Dragos Ciordas
              Dragos Ciordas Sep 18, 2013 4:44 AM (in response to Jared Conway)

              Hello Jared,

               

              Thanks for you response.

               

              I have 2 processors, each with 6 physical cores with hyperthreading (x2 cores) = 24 total logical cores. It is a HP Z620 machine.

               

              This is why I allocated 4 CPUs to each on 6 simultaneous simultaneous, so basically each simulation has 4 cores reserved just for itself. The processors have a low clock speed (2.0GHz) so I need to make maximum use of all the cores to run it optimally on this computer. This is a work computer and I did not have a say in the spec or I would have gone for a higher frequency, lower core number version.

               

              The same exact simulation is perfectly stable with 1 run at a time but only uses around 15% on the CPU. When running it with 6 simultaneous equations Solidworks' average CPU use is in the 80% area so there is a clear performance increase. I have tested, and in the case of an 1 hour 20 mins simulation, there is a 50% drop in the total time (3 simultaneous simulations take 2 hours instead of 4 hours of sequential ones).

               

              I have tried another computer, with two Xeon E5620 CPUs (8 logical cores), same Windows and Solidworks version and 8GB RAM and the same crash occurs. Newer Solidworks versions are not an option at the moment.

               

              The reason only 15% of the CPU is used is because Solidworks does not make full use of all the cores (only a few are being used while running it 1 sim at a time). 15% total use corresponds to about 4 logical cores out of 24 being used, which seems about right as the speed of each simulation does not greatly increase after that point. That is why I need to figure out a way to make use of the other 20.

               

              The simulations have been simplified as much as possible, but without any compromises so no changes can be made to the model which would make the simulation take less or use more CPU. Also, the task at hand is to prove the results over 2 flow rates and a pressure range so the number of scenarios has been kept to the minimum possible anyway, there is no way I can remove any of them and a parametric study would not work for this case.

               

              I assumed a Windows/Solidworks simulation limitation as well, but based on https://forum.solidworks.com/message/290603, and https://forum.solidworks.com/message/338235 there are people doing simultaneous simulations like this without a problem. I do not believe it to be a Solidworks limitation because it has been around for a while (2008-2009 I think). Also, based on what I was able to find on forums and such I have not been able to see any other people with this issue and there would be a lot more if this was indeed "normal".

               

              Will try to run multiple Solidworks versions, other than the journaling/auto-recover issue this should work. This is not ideal though at is needs more setup time. Simultaneous runs would still be preferrable, but I they don't work, there is not much I can do about it.

               

              Regards,

              Dragos

            • Re: Flow simulation 2012 SP5.0 batch simulation crash on x2+ simultaneous runs
              Dave Laban
              Dave Laban Sep 19, 2013 4:46 AM (in response to Dragos Ciordas)

              For what it's worth..

               

              You mention that you had set up 6 studies using 4 cores each, utilising all 24 of your logical processing cores.  We have always been advised by our support company that with any simulation where you're given a choice as to how many cores are used, you should not use 100% of your available cores.  Instead, avoid using 1 or 2 cores so that Windows has still got some overhead to manage all the other processes going on with your PC.

               

              Sounds like this may not be the issue here but it may help with things further down the line.

              • Re: Flow simulation 2012 SP5.0 batch simulation crash on x2+ simultaneous runs
                Dragos Ciordas
                Dragos Ciordas Sep 30, 2013 9:53 AM (in response to Dragos Ciordas)

                The issue has been resolved.

                Stability improvement was seen after we started using an SSD and a full computer format and rebuild, but what seemed to have fixed the issue was replacing one of the CPUs altogether after it burned out. It would seem that the true cause of the problem was faulty hardware.