It looks like the RealFlow Water extinguishing a FumeFX Fire is becoming the signature demo of Ember (which was sort of intended anyway), so here is a discussion of the setup used. The actual RealFlow data in around 1GB and the FumeFX is also not very small, so you will have to simulate your own to replicate the demo.
Here are the basic ingredients:
*A FumeFX simulation with a teapot burning using pretty much default settings, Spacing of 6.0, Grid 400x400x400 units.
*A PRT Loader with a water running down over the teapot.
*A SIM Ember to combine the two, Solver set to None, all spacing set to 6.0
*Optionally, a PRT Ember to create particles from the SIM Ember to render in Krakatoa.
[size=150]The SIM Ember Setup:[/size]
The Initial State Flow is the default 0.0->Density
The Simulation Flow has 3 output channels: Velocity, Density and Color (this one is optional)
Here is a discussion of the Velocity and Density channels individually, with the rest collapsed:
- In the above flow, the InputField operator reads the data from the FumeFX object (it could also read directly from the FXD files on disk, but in my case I had the FumeFX still in the scene)
- The Velocity is then multiplied by 30.0 (the FPS settings of the scene) because FumeFX provides the values in units per frame, but our tools including Ember work in units per second.
- The Velocity is output as the Velocity Field of the SIM Ember object to be used to advect the Density field.
This is the part of the Density field flow which replicates the FumeFX simulation, with the portion responsible for the RealFlow interaction collapsed temporarily for clarity.
- In the above flow, we use the Fire channel of the InputField operator and check whether it is greater than 0.0.
- We also take the Teapot used as emitter in FumeFX, create a LevelSet from it and compare the Distance channel to see if it is less than 5.0. This means that if a SIM Ember sample is within 5 units to the teapot’s surface (positive values are outside of the surface), AND the sample finds Fire there, we will assume we are supposed to set that sample’s Density to emit Density.
- We use the result of this logic into a Switch (10) operator which, when TRUE, adds the value of 1.0 to the incoming Density, and when FALSE just passes the incoming Density without changes. What this does is produce more “smoke” where the teapot is burning, and just leave it as is where not.
- The output of this goes through another Switch (17) which is responsible for the interaction with the water. We will look at it below. The resulting Density goes out to the Density field of the SIM Ember.
Above is the interaction part with the RealFlow simulation.
- We take the ParticleSumRadius operator and sample particles from the PRT Loader containing the RealFlow simulation within a given range (4.0 units in this case. Note that the Radius will be exposed in the future as an InputChannel to simplify the tweaking of the setup). We sample in World Space using the Position channel which is the position of the SIM Ember sample.
- In this simple example, we don’t even read any channels from the particles, we just count how many particles were inside the radius. If there were less than 1 (read: 0), the output is TRUE and the Switch 17 passes the Density calculations described in the previous segment. But if there are more or at least as many particles as the Water Threshold (E3), the Switch (17) will set the Density channel to 0.0 and thus KILL the fire/smoke in the SIM Ember completely at that location!
- Obviously, increasing the Water Threshold will mean that more particles are required to kill the fire. With the current settings, even one particle within the sample radius will be enough, but you can tweak it…
[size=150]The Simulation:[/size]
- When the SIM Ember runs this simulation, it pumps Density values into the grid where the original FumeFX had fire close to the surface of the Teapot. (This logic could be changed to simply use a Temperature threshold to emit particles where the Temerature is high, but I went with a surface-based test instead. Feel free to change).
- Then the Velocity field of the SIM Ember is set to the Velocity of the FumeFX simulation, so our Density is advected around and resembles very closely the plume look of the FumeFX sim. This way we are replicating the data by reflowing a Density field emitted based on the FumeFX data using the FumeFX velocities. Note that the SIM Ember Solver is set to None, thus the Velocity Field is not modified to be Divergence-Free. Fire simulations are not divergence-free. Setting the Solver to “FFT Solver” would produce a different look and won’t replicate the FumeFX simulation correctly.
- Since we now have our own independent simulation which mirrors the motion of the FumeFX but is on itself history-dependent, we can kill the Density values anywhere we find “water” particles (or using any other rules), and the simulation will take that into account. If we were reading the data from FumeFX verbatim (like PRT Ember does in one of the videos I posted), we would not be able to do history-dependent calculations and setting the Density to 0.0 on one frame would not affect the following frames…
[size=150]Possible Enhancements:[/size]
The logic for extinguishing the Density could be made more interesting. For example, we could affect the Density gradually, so on each step the Density would be reduced instead of resetting to 0.0 immediately, and a threshold could be used to set it to 0.0 once it is reduced below it. In other words, we would need multiple frames to get rid of the Density, so if just one drop of water fell at a point and then no more came, the burning would continue, and it would need a consistent stream of water to affect it.
Another thing we could do is actually sample a particle data channel and affect the Density accordingly. For example, we could measure the Sum Density, the Velocity, even the Color (blue particles could affect the fire differently than white particles etc.) and use that to decide whether or not or how much to reduce the Density… A lot of flexibility here.
Some other improvements that could be done - the Velocities of the PRT Loader could be used to affect nearby smoke, so when the water is falling down, it contributes a “shockwave” in the air around it to disturb the FumeFX simulation.
Also we could emit a separate field that represents the water vapor produced from the extinguishing of the fire, and let SIM Ember advect that too…
I did not show the Color channel setup, but it was quite simple - depending on the Temperature channel and whether the sample point was considered emitting Density or not, I set the Color to either a gradient of red/yellow to look like a fire, or to blue to represent the smoke. In the future, we might be able to also read the Color data from FumeFX 3 directly…
Hope this explains the setup so you can try to replicate it.
I could post the scene, but without the RF data it will be relatively useless, and you should learn to set up these flows yourself anyway 
You can also use any particle source (including Particle Flow particles) in place of a RealFlow sim, or even change the logic completely and extinguish by using, say, a mesh volume or even a Sphere Gizmo that inhibits burning inside its radius…