Hi,

we're using the latest release 13.0.314
So, I'm wondering about the multithreading.
Quiet now for testing purposes we built a small scene where a rock falls into a pool with water. So RBD object, static object and a flipfluid.
During cooking I had a look into the process explorer.
The workstation where we done the tests are a dual Intel Xeon E5-4650L with 32 boxes.
Unfortunately there is not one Prozessor wich uses more than 5%.
Specially the liquid simulstions would (and should) benefit from multithreading….
And if it should be multithreaded, why it dont use the hole horsepower, just 2 to 5 %?

I thought its fully multithreaded?

Thanks in advance for further informations.

Cheers

You can hunt down the slower culprit nodes with the Performance Monitor in Houdini/Window menu - they will glow the red!

Hi Marty,
thanks for the tip but it doesnt give me an answer to my question….

:wink:

Cheers

Those horsepower displays are not always easy to read. If you have a lot of cores and they are all at a few % only, it's a hint that in reality the whole box is idle but one core is blasting at 100%.

Also, nothing is “fully multithreaded”. Some parts are, others are not. That's why you must use the aforementioned performance monitor to hunt your culprit down.

There are a lot of other factors that could come into account, cache sizes insufficient, your temp/cache folder bandwidth might be network bound etc.

Follyx
Hi Marty,
thanks for the tip but it doesnt give me an answer to my question….

:wink:

Cheers

I'm sure SideFx could code up some junk code that appears to be multi-threaded, but one would hope that they put in optimised code. So, although this pdf link doesn't give an answer to your question it may provide some context to taking elements, nodes as I original wrote, of the program multi-threaded:

http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf [multithreadingandvfx.org]

Hope it helps.

Thanks a lot.
This pdf offers a lot of answers.

Cheers

Thanks for sharing the .pdf!
Very interesting stuff

Follyx
The workstation where we done the tests are a dual Intel Xeon E5-4650L with 32 boxes.
Unfortunately there is not one Prozessor wich uses more than 5%.

Cheers

I've been running some quick tests and am getting a lot more that 5% per core on OsX - Would it be possible to upload your scene

H.13.0.325

I don't find it hard to get most procs working above 60% I just took MartybNz's scene and reduced the separation to 0.01

The first peak in the graph is are his defaults, the second is the smaller separation. cranking the number of particles up to 80 Mill in my own sims I will quite often reach an average of 80% usage on all procs


what platform are you on? my understanding is that linux is always the winner for performance

Interestingly running Houdini on one core, houdinifx -j1, pretty much fully uses a core when the particle separation is set to 0.01.

I have another question but it is about FINITE solver. For days I have been tryng to figure out why my simple finite simulation is so slow, and I have been trying to optimize this optimize that, and today I checked the core usage and I can clearly see that finitesolver uses one core usualy above 95%. Is multithreading not implemented yet.

I am on centos and H 13.0.288.

I was thinking to use this for production for a really cool movie on a giant demolition scene( not for demolition itself but for other elemnts on top of demolition)

I have another question but it is about FINITE solver. For days I have been tryng to figure out why my simple finite simulation is so slow, and I have been trying to optimize this optimize that, and today I checked the core usage and I can clearly see that finitesolver uses one core usualy above 95%. Is multithreading not implemented yet.

The finite element solver has multithreading, but some of this multi-threading is enabled only when there are enough points in your geometry; for small numbers of points, multi-threading does not give a speed advantage.

Could I take a look at your file? Perhaps I can give you some advice on how to optimize your simulation.

Michiel

I am offwork now, first thing tomorrow, I will prepare the file, thanks for the interest. Like I said, my shots can really benefit from this tool I guess, so I really want to make this one right

michiel

I have another question but it is about FINITE solver. For days I have been tryng to figure out why my simple finite simulation is so slow, and I have been trying to optimize this optimize that, and today I checked the core usage and I can clearly see that finitesolver uses one core usualy above 95%. Is multithreading not implemented yet.

The finite element solver has multithreading, but some of this multi-threading is enabled only when there are enough points in your geometry; for small numbers of points, multi-threading does not give a speed advantage.

Could I take a look at your file? Perhaps I can give you some advice on how to optimize your simulation.

Michiel

Ok here is a simplified low res version of file.

SIM_LEVEL_01 DOP is for Bullet Sim, resulted cache goes in to SIM_LEVEL_02 as deforming static mesh.

SIM_LEVEL_02 has one solid one cloth object, cloth is teared by the sop solver, ( as far as I know built-in tear is bugged at the moment)

The cloth is too soft, I need to make it like soft sheet metal or plastic, but when I increase the stiffness etc , it gets blown out, so I am still far from it.

This mesh needs to be duplicated 8 times on -x axis which I already linked with copy sop. and I will have some close ups. But for testing I work on 1 copy

So I have a few questions regarding this scene.
1) I really dont seem to be getting an average of 20 to 30 % over my 26 cores

2) In SIM_LEVEL_01 DOP , objects are activated with sop solver, but when I do like this some pieces seem to never wake up, very small number.

3)When objects are active by default without a sop solverr activating them, a glue constraint network works as it should, but when I activate the objects with a sopsolver, even If I change the strenght to 1, I still dont get any motion( by gravity) unless they are hit by some object)


Thanks in advance again.

PS:

I am open for suggestions of any kind

Thank you very much for your file!

In response to your questions:

1 A sheet of cloth is closely attached to the static geometry, that means that all polygons of the sheet are colliding with the deformating static geometry nearly all of the time. This means that most of the time is spent on collisions. This part is not yet fully multi-threaded, which explains why you're not seeing much use of your cores for this use case.

I've created issue 60554 for questions 2 & 3, which seem to suggest that there may be a bug in the activation.

It may be simpler to do the entire sim with the FEM solver: The danger of doing a layering of two separate sims is that the solid and cloth objects in the second sim are very likely to get trapped between the deforming pieces of the first sim. At the same time, the attach constraints will be trying to pull the cloth back to the surface of your fracturing bullet pieces. This means that there are three types of forces fighting each other: the internal forces of the cloth, the cloth-attach forces and the collision forces, which may lead to instability and bad-looking behavior.

I would suggest trying to make the entire bridge out of a single Solid Object (a connected tet mesh) in which the fracturepart primitive attribute is used to designate the different parts. I've created a very rough example that shows this idea. The top layer is thinner and has a different fracture pattern than the base layer. I've made the base layer weaker using multiplier attributes for stiffness. Also, I've used the finite element embedding feature to add a layer of ashfalt to the top layer that breaks along with it.

Michiel

tricecold
2) In SIM_LEVEL_01 DOP , objects are activated with sop solver, but when I do like this some pieces seem to never wake up, very small number.

A bug in the Bullet Solver was responsible for some small pieces appearing to be stuck. This bug was fixed in Houdini 13.0.347.

tricecold
3)When objects are active by default without a sop solverr activating them, a glue constraint network works as it should, but when I activate the objects with a sopsolver, even If I change the strenght to 1, I still dont get any motion( by gravity) unless they are hit by some object)

Glued objects not moving due to gravity is often the result of including a piece the solver cannot move (eg. an inactive or static piece). In your scene, the stuck pieces prevent the glued objects from falling due to gravity. With Houdini 13.0.347 or later, they will fall due to gravity as expected.

great news, thnx for all the fixes. Many small to mid level studios rely on built-in solvers, as we don't have the budget to develop our own propriety tools, so thanks for fixing it.

As for the multithreathing and my test scene, I divided my solid objects to 8 solid simulations as they actually almost don't collide in between the sections and I do get better results now. I do get some primitives getting huge sizes altough, but I intend to start a new threat on how to stabilize large scale solid simulations.

MartybNz

Follyx
Hi Marty,
thanks for the tip but it doesnt give me an answer to my question….

:wink:

Cheers

I'm sure SideFx could code up some junk code that appears to be multi-threaded, but one would hope that they put in optimised code. So, although this pdf link doesn't give an answer to your question it may provide some context to taking elements, nodes as I original wrote, of the program multi-threaded:

http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf [multithreadingandvfx.org]

Hope it helps.

I found some good information on this PDF ,Tnx :wink: :arrow: