This content has been marked as final. Show 8 replies
Some information on your system and OS might be useful.
I've experienced a wide range of random and not-so-random crashing with FW. Memory fragmentation seems to be the most plausible explanation. If you don't have enough memory for the problem to avoid allocation issues due to fragmentation it just won't make it.
Here's something I've been trying lately...too early to report on whether or not it truly helps, but here it is: Do a pass where you ONLY generate your mesh. Save everything, shutdown SW and, if you want, reboot the computer.
Before starting SW, kill every process that you won't need. Windows Search, Google Desktop, Antivirus, automated backups, messenger are some of the programs that you may want to kill.
Once you've done that, restart SW and run your simulation. The theory is that FW will not fragment memory as much because it doesn't have to generate the mesh. It'll just load it from disk and go.
Let me know if that helps.
Well, the computer I'm using should have no trouble with the model... (since this computer is designed as our main 'CAD Station').
Windows XP Pro x64 edition
Intel Core 2 Quad CPU
2 GB of Ram
Nvidia Quadro FX 1700
Only using air
Other description is up at the top...
What I found after some experimenting is that it's not the solver that's having the difficulty... it's loading the results. (I found this by deselecting the 'load results' option before you initiate the run sequence.) The program solves everything no problem in 41 iterations, but when I attempt to load it FW crashes:
"An error has occurred and SolidWorks needs to re-start."
Any ideas? Thanks.
... Well contrary to my comment above, I just attempted to re-run the calculation to double check that it's just a loading issue. The result is that even de-selecting the box to have the results load after the calculation is completed... still ended in a crash on the last iteration.
Hopefully you've solved your problem by now. My recommendation is that you add more memory to your system. 2GB is pushing it. I'd go to 4GB minimum, 8GB+ if your motherboard will support it.
I learned the hard way (weeks of horrible productivity issues) that memory problems with FW are severe and the only way to fix them is to throw more money at the machine. Having a workstation that is your "main CAD system" means nothing, even if it works just fine with any other software package installed on the machine.
I completely disagree with these comments. I run Floworks on a 32 bit dual core laptop with 2GB of ram c/w GO 7600 graphics (hardly note worthy) and on a 64 bit quad core with 8 GB of ram c/ Quadro 1500 graphics. I frequently run problems in the 250k cell size on the laptop with out issue.
I am not saying your problems don't exist but what is being reported in this post is in no way typical in my experience and I have been using the code for about 10 years and many other codes prior to that.
The issue for me seems to be related to the use of batch processing and configurations.
If you can spare 60 hours of processing time I'd be happy to send you a model that causes problems and see if you can run a simulation without problems on your 32 bit system. I got my VAR deeply involved in the troubleshooting process and the conclusion seemed to be a pretty resounding: Switch to 64 bits.
The productivity killer here was that we'd setup these overnight or over-the-weekend runs of multiple configurations and the darn thing would lock-up or crash five or six hours into the run. You come into the office on Monday to analyze results and setup new runs only to find out that you have to burn that whole week running sims one-by-one because of what happened.
I've run additional experiments to try to understand the mechanism through which this happens. I seem to have had the most success by running a pass where I only generate the mesh for each configuration to be analyzed without running the solver. I then save, close everything, reboot, restart SW/FW and run the batch solver --this time, of course, no meshing is necessary. So far that has produced the most runs without crashing. It all points to this issue of memory segmentation.
BTW, I've seen it crash with relatively small models ~100K cells or so.
If the system crashes after simulation completion, it can easily be that the data is not written into memory of calling SW add-in in a correct way... Then, the read attempt, first chance unhandled exception and bye bye Kansas When I once had the similar problem on CosmosWorks (not Flo) I have reinstalled the OS, SW ans CW from scratch and the problem has gone.
BTW, REMEMBER to turn the automatic save ON (it is off by default),
in Calculation Control Options - Table of Savings.