Skybar
The error message it gives you says it all; “No viscosity solve because all fluid was extrapolated into the collision field”.

In other words, reduce Surface Extrapolation under Volume Motion -> Collisions on the FLIP solver. OR, reduce the Particle Separation, which in turn will give you smaller voxels and then the Surface Extrapolation won't have the same radius at the same value.

Right, that error comes from this change:

Friday, November 15, 2013
Houdini 13.0.235: The Viscosity solver now attempts to detect bad collision fields, which can lead to no viscosity solve or freezing fluids, and issues a warning in that case.

It could probably offer a more useful warning, but this situations typically arises from a “bad” collision field, which in the case of a collision VDB usually means insufficient External Bandwidth. In that case all distance queries return a value inside the extrapolation distance, and the entire field incorrectly looks like it is filled with a collision object.

This should be fixed in tomorrow's daily build, along with a couple of other POP Replicate issues:

Fixed several issues with POP Replicate: The Use Inherited
Velocity setting was resulting in zero initial velocity.
The lifespan of replicated particles was always inherited from
the source particles; now it is always set from the Life
parameters. Finally, the Inherit Velocity parameter was being
applied twice, so its effect was squared. This has been corrected.
Use the square of your current values to match existing simulations.

Sometimes MacCormack advection can cause minor artifacts, so it might be worth trying BFECC advection for density and velocity. It's a bit more expensive but less prone to artifacts. (Advanced | Advection tab)

5DN
I'd tried your advice and loads of alternate methods I can think of to no avail.

I get error message:

OpenCL Exception: No OpenCL platform found. (-32)

Hmm, you get this error even when no environment variables are set? It could be a driver problem, but by default the Nvidia drivers should include an OpenCL driver. Your regular Nvidia video card should at least show up in the About Houdini | Details box as an OpenCL device.

Have you tried any other OpenCL-based software like LuxMark?
http://www.luxrender.net/wiki/LuxMark [luxrender.net]

Very interesting tests, Dan. As much benchmarking as we've done of FLIP, I don't think we've ever tested hardware affinity with Use Preconditioner off. Jacobi preconditioning is a very simple pre-conditioning scheme that is trivial to multithread but consists of a few operations over very large memory buffers, so represents the classic case for being memory bandwidth bound.

There's not currently any way of setting affinity at the level of detail you're describing in Houdini. We're mostly limited to what tbb (Intel's Threaded Building Blocks) gives us, and there's only limited support for hardware affinity (you can read what they offer here [software.intel.com] if interested)

As I understand it, we might see a speedup using the TBB affinity tools if everything fit into the cache, which for large FLIP sims is clearly not the case. There might still be some speedup available from enforcing thread affinity across internal iterations of the pressure solve, but we'd have to do some testing. Frankly I'm skeptical it will benefit, as I think the limiting factor is on which bus the memory is allocated in the first place. I'll put in an RFE to test thread-level affinity, however.

(The TBB forums have several posts asking how to solve the NUMA problem, so you've identified a common one, I'm afraid).

robinlawrie
one quick question.. using Johner's method, the mud wont stick to the tyre and wrap around it.. however does this mean i will lose the effect of mud being thrown out backwards by the wheel if it spins?

possibly what Jeff was getting at with his suggestion to control stickyness by wheel rotation velocity.

For coarse control you can just turn down the Scale parameter on the Gas Stick on Collision in the setup I attached. That will just use more of the original collision velocity and add partial stickiness back into the sim.

For higher grain control, yes you might try one of Jeff's excellent suggestions.

robinlawrie
im not sure if im asking a silly question, or if nobody knows the answer, but this has really stopped me dead at the moment. i want a mud that can be pushed around but not stick to geometry unless i specify.

Definitely not a silly question. The viscosity solver currently only supports a “no slip” condition when considering collision velocities, which essentially means the “stickiness” between collisions and fluid is the same as internally to the fluid. Improving the viscosity solver to support a varying amount of stickiness is a good RFE; I'll add it to the bug db.

In the meantime you can cheat a bit by manipulating the collision velocity field before it goes into the viscosity and pressure solves. Essentially you want to mix the fluid velocity that is tangent to the collisions back into the collision velocity field. So when the viscosity solver looks up the collision velocity it will actually use the fluid's velocity in the tangent direction. The pressure solver ignores tangential velocities anyway (enforcing only a non-penetration constraint), so as long as we modify only the tangential velocities we should be OK using that modified collision velocity for both solves.

Fortunately there's a DOP asset that will do this for you: the Gas Stick on Collision DOP, which ironically we can use in reverse to achieve a non-stickiness by reversing the fields it operates on. In this case it mixes “vel” (fluid) into “collisionvel” (collisions).

This won't work at the fluid boundaries since those are handled differently inside the viscosity solver. If you want slippery walls you'll need to create actual collision geometry for them.

And I'm sure there are cases where this won't work that I'm overlooking, but it's worth a try for your setup. See attached .hip and .mp4. The first pass through the flipbook shows with the velocity modification active; the streamers show modified velocities. The second pass through just shows the default behavior.

Edit: I should add, the Stick on Collision DOP supports scaling its effect via an external field, so you should be able to control the location of the effect. Also it's just an asset with a GasFieldVOP inside, if you want to look at how it works.

As of 12.5, the Transform Pieces SOP will do exactly this transformation.

http://www.sidefx.com/docs/houdini13.0/nodes/sop/xformpieces [sidefx.com]

Solitude
IIt seems to fill up my available ram, but in terms of simming speed it held steady, and the computer was still quite responsive. Still, guess I'll be setting up dual boot this weekend.

Yes, the allocator (tbbmalloc) allocates memory from the OS in pools and manages them itself for speed. When memory gets fragmented, it can't release these pools back to the OS, although it can still use the free memory within them. The Linux allocator (jemalloc) does a much better job of returning that memory to the OS.

Linux has always been the best OS for large scale simulation, but it's even more true at the moment.

tricecold
I suppose this issue applies to other tools in Houdini 13 also, like Pyro, RBD multisolvers etc, on windows, please confirm.

With Reseeding and the boundary layers in the OceanFX tools, the FLIP solver is often creating and deleting large numbers of particles each timestep, which puts a lof of pressure on the memory allocator. So it seems to show the problem the worst by far. Many other tools that don't create and delete memory as frequently won't be affected much (if at all.)

With H13 we moved to a new memory allocator under Windows that is much faster than the default one provided by Microsoft. Unfortunately it can fragment memory over time, which looks a lot like a leak, though technically speaking it is not.

Until we can work out a solution, we're recommending running very large simulations under Linux if at all possible.

Also look at the Volume Trail SOP, which lets you build them directly in SOPs.

aty84122
If it use double precision, the GTX580 more faster than GTX780?

It uses single precision, except in a few rare (optional) cases that involve calculating the residual error in the solve. So I would not make any evaluation based on double precision performance, at least for Houdini.

pbowmar
I notice that HOUDINI_OCL_MEMORY_POOL_SIZE=.5 isn't working for GPU mode, I set it to .5 of my 4gb card, but Houdini reported still only 1gb. Perhaps that's just the diagnostics are wrong?

Just so we're using the same terms, the memory pool is just an acceleration method: allocating memory on the GPU is slow, and we re-use lots of identical-sized memory buffers during the solve, so it makes sense to have a pool of recently-used buffers for quick re-use. The HOUDINI_OCL_MEMORY_POOL_SIZE just sets the amount of total GPU memory available for that pool of buffers. The solver works just fine with it set to zero; in fact you'll have more memory available for the solve itself, but you'll pay a small price in performance.

So normally only a small amount of memory is allocated for the memory pool (12.5 % of total device memory IIRC), but you can increase it if you have lots of memory on the GPU. You usually don't, so I wouldn't necessarily recommend increasing it, since you'll run out of memory for the actual solve sooner. On the other hand, the memory pool turns out to increase performance (more than I would have thought) with the Intel OpenCL on CPU as well, where you might actually have some insanely huge amount of memory, in which case increasing the pool size might make sense.

If you've got HOUDINI_OCL_REPORT_MEMORY_USE set, the Total Memory Allocated is the total amount of device memory allocated. If your GPU is also your display device, you'll never get close to 4GB as there's too much other memory being used for display buffers and textures and such. The In Memory Pool is the amount of memory in the memory pool, while Active Memory is the amount currently taken by the buffers in the current sim. These two numbers should add up to to the Total Memory at the end of each timestep.

pbowmar
Negligible difference.

Wondering if there are other variables?

The basic idea is to minimize the amount of data that has to be copied from OpenCL memory back to regular memory (even though on the CPU they are the same *type* of memory, they are stored in different formats: dense grids for OpenCL vs. tiled for regular CPU).

That means turning off caching since that copies the data for the entire sim, and not displaying the results of each frame in the viewport. So for interactive work the memory transfer overhead mostly negates the increased CPU performance, as you've found. The main performance gain shows up for offline sims where caching is off and you're just writing density and maybe vel to file with Save In Background on.

Even then, the type of sim makes a difference. A resizing Pyro sim with several complicated sources and collisions is going to spend enough generating those fields in SOPs and then transferring them to OpenCL that again you won't see as much of a speedup. A “pure” smoke sim on the other hand will show a big speedup. That's basically the difference in the two attached charts, one if a pure smoke sim, one is a Pyro sim with a source and collision object. Still faster in OpenCL, but not by as much.

All of the above holds for GPU as well, or even more so, since the processor gain is higher, but the memory transfer goes across the PCI/E bus so is even more expensive.

MartybNz
Has anyone got the HOUDINI_OCL_DEVICENUMBER variable working?

There is an AMD card and Nvidia in the machine/Windows7. The Nvidia is device 0 and the Amd is device 1. When I try to switch to the AMD there is an error -33. I'm using 'set HOUDINI_OCL_DEVICENUMBER=1" to try to use the AMD card

The only way I have got OpenCL onto the AMD is to rip the Nvidia card out of the machine. It then works perfectly

You probably also need to set HOUDINI_OCL_VENDOR when they're both in the machine, as it's picking up the Nvidia one. When it's working without NVIDIA, find the exact vendor string as reported in Houdini About…, then set the environment variable to that. I believe it's:

Advanced Micro Devices, Inc.

with all the spaces and such.

The device number is per vendor, so you probably don't need to set the DEVICENUMBER once the VENDOR string is working.

The OCL environment variables are the following:

$ hconfig -a | grep OCL
HOUDINI_OCL_DEVICENUMBER := 0
HOUDINI_OCL_DEVICETYPE := ‘GPU’
HOUDINI_OCL_MEMORY_POOL_SIZE := 0.125
HOUDINI_OCL_PATH := ‘<not defined>’
HOUDINI_OCL_REPORT_MEMORY_USE := 0
HOUDINI_OCL_VENDOR := ‘<not defined>’

And you can get help for each one with:

$ hconfig -h HOUDINI_OCL_VENDOR
HOUDINI_OCL_VENDOR
Specifies the platform vendor to choose when creating the OpenCL
context Houdini uses for OpenCL processing.

Skybar

johner
Finally, we recently discovered a bug in the way the FLIP solver does velocity extrapolation around collisions, which is what's causing those small “ghost” velocities around the bottom of the container. We're currently testing a fix in the development build, but are planning on backporting to 12.5 in the near future.

Oh that explains it, I could not wrap my head around why it was doing that. Please keep us posted!

This fix has finally been backported to 12.5 and should be available in tomorrow's build:

Journal entry
Fixed a long standing bug in the FLIP Solver that caused phantom velocities
along the bottom of curved collision containers such as bowls or cups.
There is a new parameter on the Solver tab to control the velocity
Extrapolation Mode, with a default of Normal that selects the new, more
accurate extrapolation method.

This change affects velocity extrapolation around collisions and at
the liquid surface, and should provide improved, but likely different
simulation behavior. Therefore the other option for Extrapolation Mode is
Compatibility, which retains the previous extrapolation behavior for
backwards compatability.

Also, is this bug related to the strange things that happens when you turn off “Use Volume Based Collision Detection”? It has worked fine before, but now when I use it flip particles spawn out of thin air and rains down. I thought it was something else causing it before, but now I'm not so sure. You can see an example of this towards the end of this video: https://vimeo.com/70735913 [vimeo.com]

Hmm, I think you've always needed “Use Volume Based Collision Detection” enabled. FLIP needs to see collisions as SDF's to do a proper pressure solve.

riviera
I can advect using a fluid force, fine, but that uses a “force”-type advection which is not the effect I'm looking for. I tried the Gas Advect microsolver (not sure if I managed to set it up right, though), even tried to build a Geometry VOP DOP, but to no avail. (Any of these can be a solution though, as I could easily messed up their settings.)

Any ideas on how to achieve this?

I'd recommend looking at the internals of the Whitewater solver, which is the biggest user of the Pops-in-Dops toolset in 12.5. It advects the foam and bubble particles by the FLIP velocity field, basically using advection just to calculate an accurate “advection velocity” and adding it to the “targetv” of the particles.

It's a little more complicated in Whitewater, as it uses the velocity from the previous and current timestep to do midpoint advection in time, which is more accurate for things like foam, but probably unnecessary for advection by a Pyro sim. In that case you can directly use GasAdvect's ability to update a temporary velocity attribute only (not position), then add that temporary velocity into the particle's targetv with an airresist value controlling how strong the advection should be.

All these techniques are used within Whitewater.

Hanton's suggestion is a good one. Also you'll see more accurate sims with less erroneous movement at higher resolutions.

Finally, we recently discovered a bug in the way the FLIP solver does velocity extrapolation around collisions, which is what's causing those small “ghost” velocities around the bottom of the container. We're currently testing a fix in the development build, but are planning on backporting to 12.5 in the near future.

Your file is very close, just a couple of tweaks:

1) The Particle collision method only collides with other DOP Objects, not collisions brought in via SourceVolume, which directly manipulates the collision field. You need to use MoveOutsideCollision in this case.

2) Your SourceVolume DOP will solve twice per frame since you have the FLIP substeps to 2, but the original sim is only outputting data once per frame. So you're not getting properly interpolated data out of the first simulation for any sub-frames, which degrades the collision quality.

You could substep the entire DOPnet on the first FLIP sim and cache out the half-frames. Or just interpolate the output volumes from the first sim as that's probably good enough for collisions.

The attached takes the second approach, using a WhitewaterSource node to handle the interpolation, as it's already set up to handle that in case you want to substep a Whitewater sim. It also rebuilds the surface SDF within a small distance to help ensure good collisions in the second sim.

Attached, look in /out, and render the Merge ROP.