Real Flow 2013 Freezing System

[Oldcode]

Hi,

I've got a problem of Real Flow 13 freezing up my computer just as it is about to finish a frame in the Standard Particle simulation.

Everything about the computer is frozen. Windows 7, the mouse, everything. The only thing I can do is to power cycle the computer and reboot.

I'm running simulations that takes many days, sometimes over a week. I leave the simulation running when I go to bed and when I'm at work, but at random times, the system freezes and I wake up and get home from work, I've got a frozen system and a lot of wasted time and electricity.

The thing that's really crazy is its so random. Sometimes the simulation will go for 36 hours, while other times it freezes after trying to simulate the first frame.

Any idea what's going on?

This is a AMD 4.7 Ghz, 16gb ram, with plenty of hard drive space (over 4 TBs) with a recent reinstall of Windows 7 and a new motherboard.

Thanks in advance,

[DeltaJuliet]

Couple of ideas (may be bollix)

1. in prefs set stop sim on disc write error
2.does $(SCENEDIR)/log give any clues?
3.i have used ProcMon to diagnose problems in the past,may be an option http://technet.microsoft.com/en-gb/sysi ... 96645.aspx

Not too helpfull really but i thought hey, one more reply to add to the thread

Cheers

Dave.

[tsn]

It's not so easy to find out what's going on here, since you're not very specific. A couple of questions:

Do you have fluid-object interaction and are there any graphs/scripts in your scenes?
How many particles are there in the scene?
Are there any highly accelerated particles? They can really eat up all of your memory and slow down a simulation.
Are there high viscosity, sticky, or particle friction values?
Did you specify alternative paths?
Do your observe the same problem with both the GUI and Command Line versions?
Did you try to resume a simulation?
Are all export resources specified correctly?
Is the system just freezing or is it still under full load (memory/CPU)?
Which daemons are there in your scene?

Not sure if I'm the right person to solve this problem, but answering these questions (and maybe one of your failing projects) will definitely help the developers to find a solution.

[Oldcode]

Hi, thanks for you help.

Do you have fluid-object interaction and are there any graphs/scripts in your scenes?
Yes, there is fluid object interaction but there are no scripts or graphs.

How many particles are there in the scene?
About 750,000 SPH

Are there any highly accelerated particles? They can really eat up all of your memory and slow down a simulation.
I get the occasional particles popping and zipping due to high viscosity. Minimum sub steps around 300.

Are there high viscosity, sticky, or particle friction values?
Yes. Viscosity is around 200, Sticky also 200, Particle Friction between 0.01 - 0.1

Did you specify alternative paths?
Don't know what that means. Like where the scene, and bin files are located?

Do your observe the same problem with both the GUI and Command Line versions?
Only in Command Line right now. I use that 99% of the time.

Did you try to resume a simulation?
Yes, but the computer is completely frozen. No mouse or keyboard function at all.

Are all export resources specified correctly?
I believe so. The only thing I'm exporting is the bin files.

Is the system just freezing or is it still under full load (memory/CPU)?
Can't find out because as I said, the system is completely frozen. Not way to get to the Task Manager.

Which daemons are there in your scene?
Gravity and K_Volume.

Thanks!

[tsn]

Thanks for your answers Oldcode. I've added a few comments below:

Do you have fluid-object interaction and are there any graphs/scripts in your scenes?
Yes, there is fluid object interaction but there are no scripts or graphs.
Are there any particles trapped inside the objects, are there many degenerated faces, or wrong normals?

How many particles are there in the scene?
About 750,000 SPH
Hm. Such a high particle count and a viscosity of 200 could bring a system to its knees.

Are there any highly accelerated particles? They can really eat up all of your memory and slow down a simulation.
I get the occasional particles popping and zipping due to high viscosity. Minimum sub steps around 300.
Below you're saying that you delete these particles with k Volume. May sound dumb, but is the daemon connected to the emitter in the Rel. Editor?

Are there high viscosity, sticky, or particle friction values?
Yes. Viscosity is around 200, Sticky also 200, Particle Friction between 0.01 - 0.1
Is the geometry moving? If yes, set Sticky to 0, because it doesn't work with moving objects (I assume you knew that, but for the sake of completeness…). Anyway, does the simulation fail with low/default values? This is important to know. Viscosity of 200, and friction of 0.1 can be problematic. Did you try higher min substeps, e.g. 500, 750?

Did you specify alternative paths?
Don't know what that means. Like where the scene, and bin files are located?
Forgot you're on RF2013 - it's a 2014 feature

Do your observe the same problem with both the GUI and Command Line versions?
Only in Command Line right now. I use that 99% of the time.
Some simulations fail in CL mode for unknown reasons, although this is more a Mac issue. Please try to resume the simulation in the GUI version after a restart.

Did you try to resume a simulation?
Yes, but the computer is completely frozen. No mouse or keyboard function at all.
Pls. see above.

Are all export resources specified correctly?
I believe so. The only thing I'm exporting is the bin files.
There's enough space left on your HDD?

Is the system just freezing or is it still under full load (memory/CPU)?
Can't find out because as I said, the system is completely frozen. Not way to get to the Task Manager.
Maybe it's possible for you to run the task manager simultaneously so you can take a look at it when the system is freezing? Maybe you can see RAM and CPU load then.

Which daemons are there in your scene?
Gravity and K_Volume.

[Oldcode]

Do you have fluid-object interaction and are there any graphs/scripts in your scenes?
Yes, there is fluid object interaction but there are no scripts or graphs.
Are there any particles trapped inside the objects, are there many degenerated faces, or wrong normals?
I'm using highly detailed people models from DAZ, so I have to set the scale up to 25 to get the majority of the faces big enough to interact with the particles, but yes, I still get the reports of ignored faces. Some particles do leak inside, but I've got the interaction set to Outbound only so they can leak back out.

How many particles are there in the scene?
About 750,000 SPH
Hm. Such a high particle count and a viscosity of 200 could bring a system to its knees.
And it often does. But usually, you get the "Realflow.exe has experienced an error" message which kills Real Flow, but usually did not freeze the system. I just got 2014 and since it's got the viscosity option back, I'm hoping this will be the last project of its kind where I'll have to use SPH.

Are there any highly accelerated particles? They can really eat up all of your memory and slow down a simulation.
I get the occasional particles popping and zipping due to high viscosity. Minimum sub steps around 300.
Below you're saying that you delete these particles with k Volume. May sound dumb, but is the daemon connected to the emitter in the Rel. Editor?
Yes, I've doubled checked. I learned that lesson the hard way more than once, simply forgetting to put in a K_Volume into the scene and wonder why the sim is taking forever.

Are there high viscosity, sticky, or particle friction values?
Yes. Viscosity is around 200, Sticky also 200, Particle Friction between 0.01 - 0.1
Is the geometry moving? If yes, set Sticky to 0, because it doesn't work with moving objects (I assume you knew that, but for the sake of completeness…). Anyway, does the simulation fail with low/default values? This is important to know. Viscosity of 200, and friction of 0.1 can be problematic. Did you try higher min substeps, e.g. 500, 750?
Yes, I do know about the sticky not working well when objects are moving quickly, but they do work well when the objects are moving slowly which gives a nice effect. I did a test sim last night with much lower settings and it froze, but it has never frozen when not simulating or outside of Real Flow. I've never tried substeps that high. I may try it as an experiment, but that would make the simulations simply take too much time.

Did you specify alternative paths?
Don't know what that means. Like where the scene, and bin files are located?
Forgot you're on RF2013 - it's a 2014 feature
Just got 2014 and still playing with it. I tried to take a scene from my current project into 2014 without changing any settings at all, and got very different results, which is why I'm going to finish this project in 2013 and figure out 2014 later.

Do your observe the same problem with both the GUI and Command Line versions?
Only in Command Line right now. I use that 99% of the time.
Some simulations fail in CL mode for unknown reasons, although this is more a Mac issue. Please try to resume the simulation in the GUI version after a restart.
I'll try that.

Did you try to resume a simulation?
Yes, but the computer is completely frozen. No mouse or keyboard function at all.
Pls. see above.
Okay. I though you meant before restarting the system.

Are all export resources specified correctly?
I believe so. The only thing I'm exporting is the bin files.
There's enough space left on your HDD?
Yes, I have a 4 Terabyte drive that is used exclusively for Real Flow storage. It's not even 50% full.

Is the system just freezing or is it still under full load (memory/CPU)?
Can't find out because as I said, the system is completely frozen. Not way to get to the Task Manager.
Maybe it's possible for you to run the task manager simultaneously so you can take a look at it when the system is freezing? Maybe you can see RAM and CPU load then.
Good idea. I'll try that.

Thanks!

[LuisMiguel]

Hi,

Just for adding. Do you have a KVolume in the scene?. It is probably some particle is exploding, and the particle can go far away in the space if there is not something to kill it. It also means a huge raise of your ram memory and it might be the cause so the computer is freezing.

luisM.

[Oldcode]

Hi Louis,

Yes, I do have a K_Volume in the scene.

As per Delta's suggestion, I've tried using the GUI mode and it has not frozen once. I had been using the CL mode exclusively to speed things up. I've only been doing some experiments to figure out how to do my next shot, but so far it looks promising. The program will occasionally crash in GUI mode, but it won't freeze the system.

[Oldcode]

Hi Louis,

Just wanted to let you know that after a few weeks of doing various shots, the freezing problem is 99% gone. It did happen once when I wasn't simulating, but that may just be a fluke.

So, from now on, I'll be using GUI mode unless there's a specific need for Command Line mode.

Have you guys done any tests to see how much faster Command Line is over GUI?

From my experience, there is defiantly a difference, but not so much that I'll put up with the system freezing.

Thanks,

[LuisMiguel]

Hey,

I'm glad that the "frozen" effect is gone.

About the GUI vs Commandline, the CL is, more or less, a 33% faster than GUI.

luisM.