5 Replies Latest reply on Apr 18, 2008 6:23 AM by Andrey Aliamovskiy

    Dual Socket Xeons running XP x64 and CosmosWorks

    Nick McNaughton
      I've heard a rumour that dual socket workstations can run a second session of SolidWorks (without CWx plugin running) while the first session is running a lengthy CosmosWorks solve. Can anyone confirm, deny or test this? I've tried it with a 32 bit C2Duo workstation with no success.

      If it does work, is there any limit to functionality other than not being able to run a second session of CWx?

      We're considering our options for the next workstation purchase, running XP x64 with a lot of RAM. At the moment, we're running FEA solves up to and often beyond the XP32 memory limits, so we're looking at x64 and more RAM to get past that issue. If we can solve in the background and still be able to use the seat of SWx for modelling for those 4-5 hours, the price difference for a dual socket board might be worthwhile for us.

      Nick McNaughton
        • Dual Socket Xeons running XP x64 and CosmosWorks
          Basil Gello

          Theoretically, you can run the second instance of SW on any PC, but it will report a warning about auto-save journal busy. But, you may do it if you are using the SNL license and you have enough licenses to run two or more instances. Otherwise, the licensing system will prevent you from doing that. But, the better way would be to ask SW for implementing a new standalone server for CW same as they did for CFW., that allows you to run several analyses keeping your SW instance clean of it.

          • Dual Socket Xeons running XP x64 and CosmosWorks

            What happens when you try to run a second session of SW? You should be able to run multiple instances of SW on any computer, the second will give an unable to create journal file error but should still run. If you are going to working with multiple sessions of SW you need a multi core CPU and a 64bit OS to have enough power to work with, however I don't know that it is required.

            The only reason I can think of that it wouldn't work on your computer is if there is something in the SW licensing that is blocking it. I'm using a stand alone seat of SW, there are other users on the forum that are also running multiple instances of SW.
              • Dual Socket Xeons running XP x64 and CosmosWorks
                Joe Rochinski
                Be aware that the COSMOS solvers are multi-threaded and therefore will use all processor cores present in the system. Performance will be sluggish in a 2nd instance of SW no matter how many processor cores you have.

                What you can do though is set the "affinity" to tell your computer to only allow the solver to run on the processor cores you specify. You can then tell the new instance of SW to run on the free core(s) and you should theoretically see better performace in SW, though the analysis will take slightly longer.

                You can get to the affinity setting by opening windows task manager, going to the Processes tab, right clicking the particular process, and clicking Set Affinity.
                  • Dual Socket Xeons running XP x64 and CosmosWorks
                    Nick McNaughton
                    Thanks for the input, guys.

                    We've run some more tests since starting this discussion and had a talk to our local reseller, and it seems that the second session of SW being possible is simply dependant on available resources. We tried a smaller Cosmos solve and were able to open a second session that was sluggish, but managable. When we're running a bigger model that approaches the 32 bit memory limit on its own, all bets are off. It seems as if heading towards x64 will improve this situation, but it's difficult to quantify without jumping in.

                    I've spent a large part of this year watching the linetraces on windows task manager, and I'm not convinced Cosmos solvers are as multithreaded as they may claim to be. Using the direct sparse solver we generally see total utilisation around 50% for two cores (usually 80/20 between them). The supposedly faster iterative solver uses more cpu time (~75% total) but has been around 30% slower to reach convergence using standard settings for the models we run. It seems as if the cost effective solution is still outright clock speed - a faster chip with less cores rather than a slower chip with more cores.

                    Also, before running a second session be sure to consult your end user license agreement to see if it's allowed in your particular situation.