I ran a stress test which though I managed to save the file I did get an error message saying reactions could not save the file. I set voxel size to .1 and saving to vdb. All went well till frame 85. I was sleeping as I thought this would be an overnight job but reactions is fast…making it to frame 85 in about 10 mins. I think I was on 10GB of the Titans 12 GB went i left it so I assume it ran out of Mem. From the log it seems to have tried the 1070 and obviously could not work on that and so instead of using the CPU it just gave up.
Still I am impressed with the 85 frames at 10 mins with the last frame at 856 MB. It seems to me the bottleneck is in writing to disc even when not choosing vdb’s as default. Now I know my SATA is a slow drive but TFDv1 does not seem to have the issues, or maybe i just do not notice that. Oh for an SSD !! I will try again later today and see if I can manually flip over to the CPU. The 85 frames of the VDB’s came to 29 GBgpufail.zip (94.8 KB)
OK this time I started from the beginning using the CPU and the 240 frames simmed fine to rea files but there was no movement of this simulation, as f velocity/buoyancy was off. cpu2.zip (33.2 KB)
Has this got anything to do with caching velocity ? Generally caching velocity in TFD1 really slows the sim down and makes for huge files. I cannot see a way to not cache velocity in reactions.
There was an out-of-memory situation that Reactions does not recover gracefully from yet. Until this is resolved an app restart is necessary after an OOM situation.
Writing VDBs only happens to be faster ATM because it does not write velocity when using VDB caching, while it does when using REA caching. This will be resolved in one of the next builds. Then, you’ll notice that VDB caching is somewhat slower than REA caching.
The Project Velocity node does not support CPU operation yet. This prevents you from running the Explosion template on the CPU ATM.