FLIP takes long Simulation time

[saca]

hi,
I have tried FLIP-Fluid Simulation on river.
the looks is good, simualtion is simple way.
but it has very long simulation time, even main fluid, 7 days per 200f!

according to reference manual, some tips makes faster fFLIP-SIM.
*)volume source(not particle)
*)Statick Collision object is volume (not surface)
*)UsePreconditioner is OFF(multi-core CPU)
*)"sink Fluid"(from FLIP-Seminer somedays ago)

but I set up so, simulation time got longer.
majour parameter FLIP sim "particle separation" is 0.04(meters).
collision floor is complicated geometry.
Would there be any misunderstanding?
Is it usually necessary time?
by the way, I set up multiple source,
the emitters are Fill water at first and Adding water from backyard.

thanks.

[Atom]

You can try enabling OpenCL on the fluid solver. This will give you some speed increase if you have GPU that is modern. It won't help much on a low-end graphics card.

What is the MHz of your CPU?

How much RAM do you have? I think you would need at least 32GB of ram or better for this kind of work. When you have little RAM, data gets swapped to disk more often than needed then your sim starts running at the speed of the disk, not the speed of your ram. Do you have an SSD drive?

Try to simplify your collision geometry by replacing it with lower resolution proxy style objects. You can final render with your hi-res geometry but sim with the low resolution geometry.

If your scene is running at 30fps consider lowering it to 24fps. This will mean less simulation time for the same amount of playback time.

SideFX has a waterfall video tutorial. If you have not watched it you may find some useful tips in there.

Edited September 20, 2016 by Atom

[saca]

thanks Atom,
sorry, i have forgot my machine environment, it's important for this topic.
64Bit windows8.1, Houdini15.0.459
RAM=128GB
CPU=Xeon 2.4GHz*2(16core*2)
Videocard=Quadro K4200
SSD=No

this is high spec environment, so I have researched other's work, he can get good simulation with more shroter sim-time, even 64GB RAM.
And RAM comsume 20%~15%, CPU 70% (not distribute simulation),report by Thinkbox Deadline render farm.
thus I think, my simulation setting has Useless somethings.
FLIP settings has many parameters and complicated with each params.
Simply, Collision geometry be made low resolution you said.(the river collision statick geometry is cached into disk as volume)
I have cheked my scene solver, openCL = OFF, and i will try openCL = On.

my wonder, viewport show volume as surface polygon is not exactry, because volume can not be shown by surface.
if it is so, is the looks low not low as volume?
example PhoenixFD(3dsmax fluid plugin) show liquid as polygon surface, it show dull shape but vRay Render show very shape surface in Software render result as implisit surface.

I have tried openCL and Low resolution collision ,at first 35 frames.
and this short test shows taht low-resolution collision saves simulation time more.
I noticed from this test.
Network SIM(houdini engine, windows8.1) take simulation time 2 hours 46 minutes, local machine(windows7,full license, others same) take simulation time 12 minutes.(0f~35f)
Then of machine environment, the network environment and a license, , I think it's regarded as the cause.
I have compared several scene tutorial file scene setting, I can not see conspicuous difference in my settings.

Edited September 21, 2016 by saca

[Solitude]

Is it actually the simulation time or writing out files to the network?  Are you saving to disk on your 12 minute sim locally? Are you saving to the network on your 12 minute sim? Do your local and network machine have the same specs?  How many particles do you actually have? I don't think the scene scale is the issue here if your sim really take 12 min vs 2hr 46min., but just saying your spacing is 0.04 doesn't mean much since we don't know how big the scene is. For all we know your model is 1km across, in which case you're going to have a hard time simulating.  

[saca]

thanks Solitude,

18,500,000 Fluid particles at frame 35.(simulation range 0f ~ 240f, this frame is the beginning of the simulation.)

"12 minutes" is simulation and saving data on local machine.(simulate 0~35f, 350MB at 35f)

"2hr 46min" is simulation and saving data on network machine with houdini engine.(simulate 0~35f, 350MB at 35f)
the job submited through deadline submitter into networks render farm.

difference local machine and network machine is operating system, CUP and RAM are same spec.
local machine is windows7,
network machine us windows 8.1.

the scene is about 6~8m width river and about 50m length.(-> particle spacing 0.04meters)

Edited September 21, 2016 by saca

[saca]

I thought suddenly.

"DOP Net > Cache > Cache Memory (MB)" is 5000MB(5GB) as default.

Is it effective to increase this? (now 5000 MB)

example) 30GB(30000) on 128GB systemRAM

*)Allow cache disk = OFF(default)

*)FLIP Object > Creation > Allow Caching = ON(default)

 

[celd]

I believe that to disable caching flip sim into memory, you need to leave DOP caching on and disable Allow Caching on the flip object

[Atom]

Sometimes when a FLIP sim is not working for me I will just delete it all and recreate it. There may be a setting you have tweaked that is holding things up. But 18 million particles is a lot for 2.4Ghz machine. That is basically a laptop speed. For sims, Mhz is more important than core count. For rendering, lots of cores is better.

If you have whitewater in your sim delete all those nodes and get the underlying fluid to work first. Once that is cached out then create a new scene and bring in that cache data and add whitewater on top of that. This way you can avoid multiple sim times every frame.

[lukeiamyourfather]

I have a few suggestions. Try the latest Houdini version. Disable preconditioner on the FLIP solver. Save to a local folder.

7 hours ago, saca said:

"12 minutes" is simulation and saving data on local machine.(simulate 0~35f, 350MB at 35f)

"2hr 46min" is simulation and saving data on network machine with houdini engine.(simulate 0~35f, 350MB at 35f)
the job submited through deadline submitter into networks render farm.

If you're in a large facility with shared network storage the file servers might be too slow for the requirements of the facility. This drastic difference seems to indicate that. At some point Houdini added cache buffering so when it writes out simulation data it does it in the background (uses more memory but improves performance). Not sure if that was 15.0 or 15.5 that has it.

[saca]

thanks,
The reason using 15.0.x is that I have wanted to use PRT_ROP_Plugin.
But now, VRay-Proxy can rend Alembic particles, that(PRT) is not important way.
thus I should try latest version 15.5.x or higher.

All frames were calculated, but Local-Machine(same CPU,RAM) was faster substantially.
that's strange.

at first step, without white water is good idea.I think so too.
but in calculating main fluid, is white water calculating together?
I understand that first is calculating main fluid, next whitewater.

In other words, that's a different process.

Edited September 26, 2016 by saca

[lukeiamyourfather]

14 hours ago, saca said:

All frames were calculated, but Local-Machine(same CPU,RAM) was faster substantially.
that's strange.

Try running a simulation without caching it out. Like save it to /dev/null (assuming Linux). My guess is the file server or possibly the network itself is the bottleneck. If that's the case it might be time for some upgrades.

[saca]

On 2016/9/27 at 0:37 AM, lukeiamyourfather said:

guess

thanks a lot of ideas.

Perhaps the cause is this, Deadline "Frames per task" setting.

Export as Alembic Task should be set as 1 task per simulation frames.
The reason is that Alembic File be exported as One file with some frames.
If as 1 task per 1f then the rendering needs 240 times for working time.
in other word, It takes same work in 240 times.
it is often took mistake as new comer, of course I did it.Such mistake wasn't done any more since that.

In other hands, Main Fluid bgeo file has be exported as per frame.
thus I set as "1 task per 1f", that export frame by frame.
but "1 task per 240f" setting export file frame by frame too.
"1 task per 240f" is very faster, and frame by frame as bgeo.
but, That's about 30 times.I don't know this reason.

(in Deadline 7 I think that, I have set Main Fluid Job as "1 task per 1f", no problem.)

Houdini 15.5.607, Daedline 8(render farm)

MainFluid simulation Time -> 2Hr25m(240 frames)(particle Separation 0.04m)

Simulating other elements Now...
 

Edited September 28, 2016 by saca