Fluid simulation needs more memory than displayed #40203

New Issue

Andrew Buttery · 2014-05-15T04:07:05+02:00

Andrew Buttery commented

2014-05-15 04:07:05 +02:00

System Information
Windows 7 (64 bit with service pack 1)
Intel Core i7-2670QM @ 2.20GHz
16 GB RAM
NVIDIA GeForce GT540M

Blender Version
Broken: example: 2.70a (64bit)
Worked: unknown

Short description of error
The idea for the animation is for liquid metal to pour into a mold. The Fluid simulation estimated to use 7MB of RAM and when the mold obstacle is set to Volume then it calculates just fine.

Changing mold obstacle to Shell causes simulation to use all available RAM (16 GB) and if process not killed, crash the machine.

Exact steps for others to reproduce the error
Open the attached .blend
Confirm Mold object is set to Shell
Select Gold domain
Press Bake.

Example of memory usage. As you can see the simulation has gone bezerk and used the entire 16 GB RAM. If left, my system eventually seizes up and a hard reset (i.e. power off) is required.

cc_test_3_-_broken.blend

**System Information** Windows 7 (64 bit with service pack 1) Intel Core i7-2670QM @ 2.20GHz 16 GB RAM NVIDIA GeForce GT540M **Blender Version** Broken: example: 2.70a (64bit) Worked: unknown **Short description of error** The idea for the animation is for liquid metal to pour into a mold. The Fluid simulation estimated to use 7MB of RAM and when the mold obstacle is set to Volume then it calculates just fine. Changing mold obstacle to Shell causes simulation to use all available RAM (16 GB) and if process not killed, crash the machine. **Exact steps for others to reproduce the error** Open the attached .blend Confirm Mold object is set to Shell Select Gold domain Press Bake. Example of memory usage. As you can see the simulation has gone bezerk and used the entire 16 GB RAM. If left, my system eventually seizes up and a hard reset (i.e. power off) is required. ![undefined](https://archive.blender.org/developer/F89009/undefined) [cc_test_3_-_broken.blend](https://archive.blender.org/developer/F89011/cc_test_3_-_broken.blend)

Andrew Buttery commented

2014-05-15 04:07:05 +02:00

Changed status to: 'Open'

Andrew Buttery commented

2014-05-15 04:07:05 +02:00

Added subscriber: @AndrewButtery

Thomas Dinges changed title from ~~Fluid simulation estimated to use 7MB of RAM. Changing obstacle to Shell causes simulation to use all available RAM (16 GB) and if process not killed, crash the machine.~~ to Fluid simulation needs more memory than displayed

2014-05-15 09:58:43 +02:00

Daniel Genrich was assigned by Sergey Sharybin

2014-05-15 11:53:57 +02:00

Sergey Sharybin commented

2014-05-15 11:53:57 +02:00

Added subscribers: @genscher, @Sergey

Sergey Sharybin commented

2014-05-15 11:53:57 +02:00

@genscher, can you please have a look?

but the thing is, it's not always possible to predict how much memory is gonna to be used by the external library. And blender can only predict memory it requests from the system. Because of the fragmentation physical memory usage might be much higher..

@genscher, can you please have a look? but the thing is, it's not always possible to predict how much memory is gonna to be used by the external library. And blender can only predict memory it requests from the system. Because of the fragmentation physical memory usage might be much higher..

Bastien Montagne commented

2014-05-18 09:25:25 +02:00

Added subscriber: @mont29

Fazekas Laszlo commented

2014-06-05 21:52:24 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-06-05 21:52:24 +02:00

I can confirm this on Linux 64bit too. And the result is the same as "Shell" when the "Both" mode used. "Shell" mode runs away with the memory almost immediately but the "Volume" mode finishes quickly with low memory consumption (roughly 250 MB).

Fazekas Laszlo commented

2014-06-06 10:27:25 +02:00

So, after some debugging, this memory allocation boom happens exactly in the cycle beginning at line 531 of elbeem/intern/ntl_geometryobject.cpp in function ntlGeometryObject::initMovingPoints(double time, gfxReal featureSize).

// init points & refine...
for(size_t i=0; i<triangles.size(); i++) {

For VOLUMEINIT_VOLUME, the triangles.size() returns 64 here but for VOLUMEINIT_SHELL, it's 10364. I think this big number causes the large allocation in the cycle.

This function was called from line 1811 of elbeem/intern/solver_init.cpp. This call happens twice at the start of VOLUMEINIT_SHELL and only once at the start of VOLUMEINIT_VOLUME. The memory boom happens at the first call. I hope this helps to solve the problem.

So, after some debugging, this memory allocation boom happens exactly in the cycle beginning at line 531 of elbeem/intern/ntl_geometryobject.cpp in function ntlGeometryObject::initMovingPoints(double time, gfxReal featureSize). // init points & refine... for(size_t i=0; i<triangles.size(); i++) { For VOLUMEINIT_VOLUME, the triangles.size() returns 64 here but for VOLUMEINIT_SHELL, it's 10364. I think this big number causes the large allocation in the cycle. This function was called from line 1811 of elbeem/intern/solver_init.cpp. This call happens twice at the start of VOLUMEINIT_SHELL and only once at the start of VOLUMEINIT_VOLUME. The memory boom happens at the first call. I hope this helps to solve the problem.

Andrew Buttery commented

2014-06-06 11:54:03 +02:00

That's fantastic Fazekas!

Thanks for spending the time to look into this one and also hope this helps the developers to find the problem...

andrew

That's fantastic Fazekas! Thanks for spending the time to look into this one and also hope this helps the developers to find the problem... - andrew

Bastien Montagne commented

2014-08-11 14:47:28 +02:00

Looks like real issue would be in elbeem then… Think will just add a warning about shell options (that they might induce huge mem consumption), and close that report (and we expect a brand new system for fluid simulations in coming months…).

Thanks for the report and nice investigation, in any case!

Looks like real issue would be in elbeem then… Think will just add a warning about shell options (that they might induce huge mem consumption), and close that report (and we expect a brand new system for fluid simulations in coming months…). Thanks for the report and nice investigation, in any case!

Bastien Montagne commented

2014-08-11 14:57:02 +02:00

Also, note that mem usage annonced is the mem needed for the bake cache itself, not the mem needed to compute that cache.

Also, note that mem usage annonced is the mem needed for the bake cache itself, **not** the mem needed to compute that cache.

blender-admin commented

2014-08-11 15:02:57 +02:00

This issue was referenced by c4814c8764

This issue was referenced by c4814c8764dd5703805447e5b2930a91d5d95e88

Bastien Montagne commented

2014-08-11 15:03:24 +02:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue