GPU simulations?

[urbanite]

where should I look for the phoenix log?

[cb LLC]

where should I look for the phoenix log?

[urbanite]

The log file has been sent to support (ticket number 158-855-9382) . For some reason the forum were rejecting the attachment.

[Svetlin.Nikolov]

Thank you guys! Looking into it...

[Svetlin.Nikolov]

Hi Svetlin,
here it is. We have 5 phoenix grid in the scene I guess they all go to one log?

Hey cb LLC , indeed all grids go into one log. Unfortunately this seems like a log from a Max session run that contains only rendering and no simulation. Would it be possible to simulate the scene you sent over and grab the log file right after this is done?

[Svetlin.Nikolov]

The log file has been sent to support (ticket number 158-855-9382) . For some reason the forum were rejecting the attachment.

Hey, checked the log - the simulations that you've run range between 1-2 million voxels and take about 2-4 seconds per frame. The conservation phase for this setup takes up a huge portion of the simulation time. If you are using the Buffered method, it's quite dated and has many issues, so I've been on the line of completely removing it from Phoenix for years now - if it does not scale well, this just adds up to its other issues. A small simulation like this would also poorly utilize the CPU because it starts and stops all the time - reading the scene from 3ds Max at each simulation step, writing the cache files, updating 3ds Max's viewport preview... There definitely is a lot of room for improvement in such simulation, but in order to utilize the CPU better, a larger simulation would be better. Running the Fire preset on my machine load the CPU on average at about 70%, so if it's lower on your machine, then it really sounds like bad scaling of this particular setup indeed - I'm running an i7-6800K @ 3.4 and write the caches to an SSD.

Would be interesting to know how larger simulations performs on your machines, e.g. 50M voxels or more. There would also be differences in scaling between FLIP and grid simulations. Will run some tests on machines here in the office as well.

Thanks very much guys!

[Svetlin.Nikolov]

cb LLC , I run your 'cpu 50 max.max' scene here and my CPU was at at about 90%. From your video I see that your bus speed is 100MHz, just like mine, so my current guess is that the CPU is starving for data and cannot get fluid grid data quickly enough in order to start processing it.

My log file says that in this particular scene it's again the conservation step that takes by far the longest time, which is using the Buffered method as well, so it's really interesting how the other conservation methods perform both your machines. Can you guys try changing to a PCG and Direct Symmetric and share logs or observation if there is any visible difference in CPU load?

[urbanite]

I have send phoenix log sent (support ticket no. 158-855-9382). One of the presets (fd_fire) with over 100 millions cells. The use of cpu were much better but not consistent, but the reason of that was explain in your previous post. I am not sure where to find the option to switch the buffer off but as I said need to spend more time with Phoenix.

[georgi.zhekov]

Thanks a lot for the logs.

You can change the conservation type in the Dynamics rollout of the simulator. Here is a bit more info on that - https://docs.chaosgroup.com/display/...s-Conservation

Cheers,

[urbanite]

Ok, thank you Georgi.

[cb LLC]

here is my log with buffered, it stayed at 90 I guess because we used wetmap to put out fire
it is still slow around 1.6 mil vov where liquid is calculated at 40 mil

I will send PCG soon it is usually fast. But then the manual said used buffered for fire. Is PCG good enough for building flames?

PCG stays at 2.6 mil per second

It would be nice if phoenix 4 could get a new faster fire system

[cb LLC]

Here is log with recent pcg

[cb LLC]

cb LLC , I run your 'cpu 50 max.max' scene here and my CPU was at at about 90%. From your video I see that your bus speed is 100MHz, just like mine, so my current guess is that the CPU is starving for data and cannot get fluid grid data quickly enough in order to start processing it.

My log file says that in this particular scene it's again the conservation step that takes by far the longest time, which is using the Buffered method as well, so it's really interesting how the other conservation methods perform both your machines. Can you guys try changing to a PCG and Direct Symmetric and share logs or observation if there is any visible difference in CPU load?

Hi,
Can improve bus speed?

[cb LLC]

cb LLC , I run your 'cpu 50 max.max' scene here and my CPU was at at about 90%. From your video I see that your bus speed is 100MHz, just like mine, so my current guess is that the CPU is starving for data and cannot get fluid grid data quickly enough in order to start processing it.

My log file says that in this particular scene it's again the conservation step that takes by far the longest time, which is using the Buffered method as well, so it's really interesting how the other conservation methods perform both your machines. Can you guys try changing to a PCG and Direct Symmetric and share logs or observation if there is any visible difference in CPU load?

We had a project done 2 years ago and I remember buffered was always around 5 mil now it is at 1 mil per second. Liquids are much better now around 30-40 mil per seconds

[Svetlin.Nikolov]

Ah, there is some problem with email notifications, I didn't get any updates for this thread, sorry!

So regarding Buffered speed - we have a few hundred test scenes here, some of which have been around for 4 years or so, and we are monitoring if there is any speed degradation for any of them. Do you have the scene setup that you used before? Was is the same hardware, same version of Max, and only different Phoenix version?

It's also very important to underline that voxel/sec for FLIP sims is quite a vague measurement - FLIP sim speed is mostly governed by the number and type of FLIP particles used, and the voxel grid resolution has some effect, but it's much less important than the particle number. The more empty space you have in a FLIP sim, the higher the vox/sec number would be, but this is not the correct way to look at it. Fire/smoke sims using a pure grid solver need to calculate the velocity in each voxel, no matter if its occupied by a visible channel or not, while liquid sims can compromise with accuracy and while Air Effects are disabled, only the velocity around liquid particles needs to be calculated.

Also, please note that voxels/sec would reduce in half if you increase the steps per frame two times. Two times more conservation quality would also reduce the voxels/sec in a fire/smoke sim significantly - usually between 50-70%, but it also depends on a lot of other factors. There are tens of software options and hardware peculiarities that would skew the voxels/sec measurement, so please take it only as an informative field and compare only the same simulation with altered settings or the same simulation early and late during the timeline animation for example.

Since I've had many talks about the voxels/sec field, I'm seriously considering removing it, since it really confuses people and has very few applications where you can conclude the right thing looking at it.

Cheers!