CPU Usage while calculating very heavy scenes

[DragonsSpirit]

Hi there

I know that it takes time to distribute the loads among multiple threads/cores. As for my PC, it has 8 threads and they will only be all loaded to the max if I have multiple million particles in the scene. Now, I have a scene with a large scale Hybrido simulation. I simulated the whole grid thing, and then, as a post effect, I set the grid domain to cache mode (and the grid emitter too) to generate splash particles from it. It all works fine, BUT:

The CPU usage will pretty much never go over an average of about 20 percent. It runs @ 99% load for a second, but then again for a long time, only 13 (which is one single thread all in all). No matter on what machine, only one thread all in all is really loaded. it takes over 22 hours for 69 frames to simulate while the grid sim (2000 frames, 7.8 million particles) was done after the same time. I cannot work this out that way, it will take ages.

I have sent mails about this CPU usage issue multiple times to the support now, but no answer. So I hope to get an answer here now. Also, it is completely independent from scenefiles. The CPU usages will always be so low if I have a splash emitter or sheeter or others of that kind in the scene. Is the particle-checking of hybrido really not multithreaded??

[Alex]

Hi,

Angel is probably the best guy to provide the full detail needed to answer this post, many concepts are mixed in it.

However, meanwhile I would give a couple of things a try:
- Test those splashes generation with different thread numbers (like 1, 4 and 8 for example). Then compare those times and you will get a real scalability value. Don't expect any magic number but CPU usage percent is not be the best value for performance comparisons in most cases. Raising processor usage up to 100% is very easy but pointless when simulation time is not paired with it.

- If splashes don't need to interact among them, create an IDOC for each one. If you are using only one splash node, split it into several ones. To get an even better balance try to assign bigger areas to low activity splashes and smaller areas for those where you expect more particles. Finally, open a terminal and launch as many simulations as IDOCS for the scene with:

Code: Select all

"%RF5_PATH%/realflow.exe" -nogui -idoc IDOC_NAME scenepath.flw

You can add the "-threads N" flag to limit the number of threads used for each simulation.
If everything is right, you should be making the most of your CPU.

[gus]

Hi,

If you could send us the scene over we might be able to spot other things that might be causing 'problems'.
Have you got geometry colliding with the splashes, for example? It is always wise to work with proxy objects whenever possible.

As Alex suggested, splitting the splash generation in IDOCS is the way to go too.

Cheers,

g-)

[DragonsSpirit]

thank you people for the tips and hints. Ill check them out. The splash particles are colliding with very simple geometry and a cube with collision mode inside to keep them inside the domain. The splash particles are liquid and not dumb. They need to interact. But Ill check out the IDOCS. I already tried with different thread numbers. It does not change the calculation times. I cannot hand over the scene currently. Ill let you know what worked and what did not. If the "problem" is not solved in the end, Ill send the file.

thanks

[gus]

Hi,

Out of curiosity, what is the objects scale and the collision distance set for the particles?
That can also be slowing things down.

g-)

[Martians]

I have also been wondering why CPU usage is only around 15-20% when simulating on my 980X - I tried disabling Hyperthreading in the Bios, and noticed that this does in fact cause the cores to report 80-100% load. It even seems faster than when HT is enabled. Can there be some truth to this?