Using Max 2012 x64, Vray 2.2, PhoenixFD 2.0 (system: Core i7 920, 12GB RAM)
I have a moderately complex liquid simulation (5-10 million cells) using Foam and splashes which stalls once the simulation has got to a certain point (Never the same frame but normally around the 200 mark).
I can see no sudden change in the simulation (compared to previous frames) which can account for any significant extra computational demands and the CPU usage (around 10-20% displayed for 3Dmax.exe in TskMgr) suggests that Phoenix is doing something.
PhoenixFD and the Max UI remain completely operative during the stall and I can pause/stop the sim. Restoring or un-pausing don’t allow the sim to get past the stall point though.
RAM consumption hovers around 3-4GB during simulation.
If I switch off either the splashes or the foam the stall does not occur.
Could anyone suggest what might cause Phoenix FD to stall like this?
Thanks
the most common reason for such a behavior is too big count of the splashes/foam particles. what is the count of the particles in the last frames?
Where would I find this particle count?
I ran the simulation again to check. It stalled at frame 196 (total cells 5.7 million) and the Input roll out content display shows:
Foam 8585
Splashes 335
I then reduced the Maximal step from 2.2 to 1 (on a hunch) and it no longer stalls! by frame 332 the Input roll out content display shows:
Foam 79662
Splashes 3802
Note: This is a slow motion simulations with Time scale at 0.1 and standard gravity at 0.01.
well, i suppose the reason was big count of the splashes. we should add a limitation of the particle birth to prevent such a situations. btw, one possible reason is the use of FT advection, it produces small underwater bubbles and they very powerful particle incubators.
Thanks for your help Ivaylo,
Sorry I wasn’t very clear in my previous post.
What I meant was that in my second test (Maximal step set to 1) the simulation did not stall (at any point) and its splash/foam count was much much higher than in the previous simulation which did stall.
no, you was quite clear 
but i suspect the stall is caused by the particles explosion in the current frame, that is still not exported and you can’t see the actual particle count. we can prove this starting simulation without particles - if i’m wrong it will stall too.
Thanks Ivaylo,
It all makes sense now!
I will run another test later but I expect it will confirm your prediction!!
Yep. Forward transfer makes water look boiled. I remember boiled water was a hard task. With phx - it is simple 
Your prediction is confirmed Ivaylo!
Additionally, it turns out if I have only foam OR splashes switched on and restore the sim just before the stall, everything is ok and the stall does not occur.
Looking at the input content information for the frame just before the stall originally occurred, shows foam: 7631 splashes: 327
Interestingly, when I had only foam or splashes active (circumventing the stall) the amount of foam or splashes did not suddenly increase in number at all over the frame where the stall previously occurred or at any frame after.
well, if you have a cache file that leads to stall after restore, send it to us with the scene of course
Thanks Ivaylo,
For now everything is fine. I’ve done a lot of simulating with splashes and foam together and this stalling issue is certainly not common, so I’m not too concerned!
I will send you the files you suggested if I get further stalls.