Any news of performance improvements?

[philstopford]

Just wondering if there was news of efficiency gains with respect to the solver (or perhaps a different solver better able to leverage multiple cores/GPU). Didn't know how/where else to pose the question.

[rlguy]

Hey philstopford,

At the moment, we're working on rewriting the surface mesh generator to make better use multiple cores. Mesh generation is currently running on the GPU, but it seems like this has not been testing well and performance varies widely across hardware. It seems like it would be best to remove GPU accelerated mesh calculations in favour of a more performant CPU solution.

Best Regards,
Ryan

[philstopford]

Is there an ETA for an update?

[rlguy]

We're currently in the process of testing the new surface mesh generator and are on track to release a new version of the addon (1.0.4) on August 11th.

[philstopford]

Sounds good. Are you willing to share some performance data? :)

[rlguy]

Sure! We've just run some benchmark scenes comparing v1.0.3 and the new v1.0.4 and the results are looking good!

Here are the stats from the Cascading Water Feature scene:

The performance improvements affect the mesh generation process. We have a short post about this on this new adaptive mesher on Facebook here.

In this test, it looks like the improvements shaved off about 140 minutes from the meshing process. Note that other calculations in v1.0.4 took longer than calculations in v1.0.3. This could be explained by the fact that the higher performance meshing calculations are running ontop of those other calculations, which is decreasing performance of those other calculations. Overall, the total bake time of the simulation decreases by 89 minutes.

Also note that the mesh cache file size is larger in the v1.0.4 test. During this test we have identified a bug that was causing bumpy edges on the fluid surface and this creates a larger mesh size. This is something we'll need to work out!

And another note: the preview cache is only 6kB because preview meshes have not yet been implemented into the new mesher. Generation of preview meshes take a negligible amount of time to produce, so this should not affect the results of the test.

---

Another benchmark scene, Fluid in an Invisible Box, is ideal for the new particle mesher. This is because that scene always has fluid in a much smaller volume than the total domain volume. The new mesher only needs to make calculations where the fluid exists whereas the old mesher needed to make calculations over the entire domain.

This test is currently running and it's looking like the old mesher accounts for 45% of the bake time and the new mesher only accounts for 8% of the bake time.

---

And since these results are looking good, there is some good news! These meshing calculations can be applied to the velocity advection and some of the fluid particle calculations. Now that we know this performance enhancement works, we can work on applying these types of calculation in other areas of the simulator to increase performance in the future.

[philstopford]

Neat. Does the new engine respond better (more linearly, perhaps) with the number of threads it runs on? Is there a memory penalty from the new engine compared to the old?

Will the bumpy mesh problem be resolved for 1.0.4, or is there a forecast for a fix there in terms of time beyond 1.0.4?

[rlguy]

The bumpy mesh issue was a simple error and fixed earlier today along with a few other minor bugs. The new particle mesher will be considered complete for 1.0.4 if no other issues are found in another round of testing.

It's hard to say how the mesher will respond to CPUs with capability of running many threads. We'll have to see how it performs once released. We don't have a system with a Xeon/Threadripper CPU for testing at the moment.

The mesher calculations are definitely more parallel and suitable for running multithreaded, but it's unpredictable how many threads are optimal. There is an overhead in having the CPU switch between many threads that can negate these parallel optimizations. I'm testing on a 4core/8thread system and the mesher seems to be running the CPU at 100% for large simulations.

[philstopford]

1.0.4 does seem to be markedly better. The CPU usage is a little uneven - it's not a sustained load. I'm also seeing some GPU activity (8-10%). I'm not sure whether that's expected.

[rlguy]

This is expected. Fluid simulation is a series of many different calculation stages. Some calculations run well multithreaded and some calculations are less suitable for multithreading. And some calculations must only be run on a single thread. That is why you will see CPU usage fluctuate.

If you enable Display Console Output in the Debug Settings and open the Blender System Console (Blender > Window > Toggle System Console) you can see what general calculation stage the simulator is currently running while baking:

Each of these listed calculation stages consist of a series of many other calculations within the engine, but we don't display that much detail/info in the console output.

As for GPU usage, the addon does not run any calculations on the GPU in version 1.0.4 so that usage must be from Blender or other applications.

[mingweiLIU]

I am trying to simulating fluid in a big scene (such as on ground surface with 1km*1km) with the engine, thus I set the grid dimensions to be (1000,1000, 30), dx=1, and the time of initalization the FluidSimulation object is so long, is there any strategies for some improvements?

[rlguy]

The initialization stage mostly involves your OS reserving the required amount of memory in RAM. I just tested a domain this size and resolution and initialization took less than 9 seconds:

How long is this taking on your system? What are you system specs? Are you using any animated obstacles. Feel free to attach a .blend file and I can check it out.

- Ryan

[mingweiLIU]

My enviroment is windows10 vs2015 x64 CPU Xeon E5-2650 v3 ,my code is

The initializing info is

I don't know why it is such slow here, and also slow in generating each simuation step. I wonder whether if the more obstacle fille in the domain the efficiency the simulation is?

[rlguy]

Hey mingweiLIU,

This issue tracker is only for support issues regarding the Blender Market product. That is, only builds that are created by the FLIP Fluids team. We are not able to offer support for custom builds of the addon (or for direct use of the engine). This is due to the large variety of methods that can be used to build the program and the unknown issues associated with that. See the CONTRIBUTING.md file for issue tracker guidelines.

From your initialization times, I would have to guess that it is an issue with how the program was built rather than a hardware/OS issue. I am not very familiar with Visual Studio, so I am not sure what the problem could be. If this can be reproduced using the Blender Market product, then I would be able to look further into this performance issue.

- Ryan

[mingweiLIU]

Well, that is so pity! I think one more reason is that the version of engine in Blender-FLIP-Fluids master (1.0.2) is lower than the one you tested (1.0.4?). Are you going to update it?

[NovioK]

Baking on my machine seems to have increased using CPU v1.0.4 compared to the previous 1.0.3

Using intel i7 5930K with 64 gigs ram

[rlguy]

Hey NovioK, Thanks for the feedback!

I have a few questions:

• What GPU model were you using for v1.0.3?
• How long are the baking times of 1.0.3 vs 1.0.4 for the same scene?
• Does 1.0.4 seem to degrade performance for all simulations?
• Would you be able to attach a scene for me to test?

In general, the mesher improvements should improve baking time for scenes with high resolution simulations (taking longer than 1-2 hours to bake) with mesh subdivision set to 1. There are certain scene and fluid configurations that could result in no improvements or longer baking times, so if you could attach a scene, this could help me find ways to optimize for these cases.

- Ryan

[NovioK]

Hi Ryan,
Thanks for getting back to me.
I have 5 GTX1070's in my rig which is probably why I am seeing slower baking times with the new version.
I didn't do any proper testing of baking times, its just my impression from 2 very similar scenes that were using the 2 versions of flip fluids with a resolution of 150.
I also have to bump up the frame substeps to prevent obstacle meshes from 'leaking' to 5.
Ideally I wanted to bake at a resolution of 450 which I left over night, and only got 36 frames so far.

But I will say that I am very new to using this addon so I do need to spend more time figuring out optimal settings on my machine and possibly reduce the size of my fluid mesh to make things lighter.

[rlguy]

Hi NovioK,

I assume you have read the tips for working with thin obstacles. If possible, number three of using a thick obstacle for simulation would be good for speeding up baking if 5 substeps is already required to prevent leakage.

As for only 36 frames in a night, that sounds like you're running quite a large simulation! Here are some optimization tips that may help:

In general, the time to bake a simulation is based upon number of fluid particles and the size of the domain.

• Fluid Particles - The simulator must make calculations for each fluid particle, so if there are many, this can slow down the simulation. You can check the number of particles in the Stats Panel under the Frame Stats section. A simulation with more than 30 Million particles would be considered very large. I would not recommend simulating over 50 Million particles in general. Ways to reduce number of particles can be to decrease resolution or decrease volume of fluid in a scene.
• Domain Size - The simulator must make calculation over the entire domain grid, even if parts of the grid do not contain fluid. It is recommended to size the domain so that it fits tightly with the fluid effect that you are trying to achieve to avoid wasted space. Example: if your domain has a high ceiling and fluid will never splash up to the top, lower the ceiling of the domain. Tip: when resizing the domain, you can enable the Lock Cell Size to maintain a constant level of simulation detail (cell size) while the addon adjusts the resolution value automatically as needed.

- Ryan

[rlguy]

I will be closing this issue due to inactivity and to clean up the issue tracker. If you have any further questions/comments, feel free to add them here or send us an email at flip.fluids@gmail.com