Re: Simulating Volatile Gases and Fire

[Robert Munafo]

On 1/17/13, s.t.ri...@gmail.com <s.t.ri...@gmail.com> wrote:
> Ready is amazing! I'm currently integrating the lib into a real-time
> environment and simulating basic gas diffusion and temperature (Same rules,
> different lattices). I'd like to simulate in real-time some basic
> interactions with the gases I'm using (Purely arbitrary). Example is a fire
> starts at some x,y location in the gas lattice and what should happen is
> the gas is consumed due to it being explosive and immense heat added to the
> same location in the temperature lattice, assuming there is enough gas in
> the lattice.
>
> Wondering how I should proceed here? I'm also wondering whether I should
> try to combine the lattices together into a single one or keep
> them separate.

Is there something that gradually replenishes the fuel (gas) at all
lattice points? If so, it sounds like a forest fire model [1]

You mention the "immense heat being added" back into the system, which
sound a lot like an autocatalytic reaction (a chemical reaction where
the product of the reaction is a catalyst making the reaction happen
even faster).

Anyway, you need some specific equations to work with, Do you have a
source or a reference (like a book or a journal article) describing
the fire simulation?

[1] http://en.wikipedia.org/wiki/Forest-fire_model

--
Robert Munafo -- mrob.com
Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[Scott Richmond]

Hi Robert,

There will be 'devices' that replenish gas into specific areas of the lattice. It won't replenish in a uniform fashion. It will rely on diffusion to distribute the gas from the point of origin. A lot like the brush action in Ready really.

Having the temperature of the environment impact the way the gases act or react would be great feature - Gases could ignite at a certain temperature instead of myself adding some arbitrary catalyst into the mix as a trigger. Therefore if I want to start a reaction due to fire I would simply set the temperature to a trigger point for that gas.

In regards to specific equations - Cheap simulation is my goal. I need to perform these calculations on commodity hardware in real-time without taking more than 10% of the CPU/GPU resources. 

[Tim Hutton]

Hi Scott,

Do you need fluid flow for this? Felix Woitzel has done some very cool demonstrations of fluid dynamics. Search for his name.

Tim

--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/

[Scott Richmond]

On Fri, Jan 18, 2013 at 6:04 AM, Tim Hutton <tim.h...@gmail.com> wrote:

Do you need fluid flow for this? Felix Woitzel has done some very cool demonstrations of fluid dynamics. Search for his name.

Fluid flow is most definitely on my list. However I thought I'd try some of the more simple things as discussed above, first. I'll look into Felix Woitzel's work.

However my key lack of understanding here at the moment is how I should organize these simulations and how best to make some of them interact, as in the examples above.

[Robert Munafo]

On the library question, my approach would be to write scripts that
invoke the command-line tool and other stuff that I write myself. Tim
answered the question much better than I could.

> On 18 January 2013 09:32, Scott Richmond <s.t.ri...@gmail.com> wrote:
> There will be 'devices' that replenish gas into specific areas of the
> lattice. It won't replenish in a uniform fashion. It will rely on
> diffusion to distribute the gas from the point of origin. A lot like the brush
> action in Ready really.

Okay, then you'd want one "chemical" for the replenishment rate,
separate from one that encodes the "amount of gas" ..

> Having the temperature of the environment impact the way the gases act or
> react would be great feature - Gases could ignite at a certain
> temperature instead of myself adding some arbitrary catalyst into the mix as a
> trigger. Therefore if I want to start a reaction due to fire I would simply set
> the temperature to a trigger point for that gas.

so you'd want a 3rd chemical for the "temperature", and I think a 4th
chemical for the "amount of combustion".

> In regards to specific equations - Cheap simulation is my goal. I need to
> perform these calculations on commodity hardware in real-time without
> taking more than 10% of the CPU/GPU resources.

You'll definitely need an exact mathematical description of some kind.
It sounds like you're inventing a new system, rather than replicating
something you saw elsewhere. That's fine, but you might want to start
by studying some of the existing systems in Ready (by which I mean
"hacking around to see what happens" :-)

The "mutually-catalytic_spots.vti" pattern has five chemicals, where
two of them are a Gray-Scott system and the other two are another
Gray-Scott system. (The fifth chemical, "e", is just a way of
combining the others together for display). The a and b control the c
and d, but not vice-versa.

[Scott Richmond]

Hi Robert,

Thanks for the detailed reply! Its really helping. I think I can see where you're going with regards to how to get all these systems working within a single calculation, and I think it is ultimately where I want to go. But I'm still struggling to grasp it all. Linked below is the high level design I'm going for with my current understanding of it all. I'm hoping you can provide some direction on it. The drawing is freely editable by anyone so please feel free to leave your comments or change anything.

https://docs.google.com/drawings/d/16b7b0RZgD4KFmtY8sNQ_xLjAsCzbccvb4DSe-Imv20g/edit

In the mean time I'm continuing to hack around in Ready to see what I can come up with. I think for the most part I'll be using the simple diffusion equation. It seems my biggest challenge right now is just getting my head around connecting it all.

First steps are temperature and oxygen (or any gas) diffusion. From there I want to move on to some of the more complex interactions.

[Tim Hutton]

Just a minor point: the c-d pair *does* affect the a-b pair (and vice versa). The small red spots (c-d) can only replicate inside the large green spots (a-b), and the large a-b spots can only replicate when full of small c-d spots. It's arguably a simple living system: there's a property (presence of both types of spot in one region) that both causes replication and is maintained by it, all contained in a local area that maintains its boundary (as in autopoeisis). All that's missing is a packet of information that can evolve, and then this really would be life.

--
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[Scott Richmond]

Hey Tim,

Thanks for replying. I thought I may have scared you guys off hah.

Yeah after playing with the heat interpolation pattern some more yesterday I realized that. I basically need the 'wall' chemical to define a dead zone and I can't think of a way to do that using only simple formula math - I need to only use the surrounding blocks that are > 0 on the well chemical.

Right now the only way I can see that working if via a long string of if(b.nodeToTheLeft > 0) {nodesToDiffuse.add(a.noteToTheLeft)}, etc in a kernel pattern.

[Robert Munafo]

On 1/19/13, Tim Hutton <tim.h...@gmail.com> wrote:
> Robert Munafo wrote:
>> [...] The "mutually-catalytic_spots.vti" pattern [...]

>
> Just a minor point: the c-d pair *does* affect the a-b pair (and vice
> versa). The small red spots (c-d) can only replicate inside the large green
> spots (a-b), and the large a-b spots can only replicate when full of small
> c-d spots. It's arguably a simple living system: there's a property
> (presence of both types of spot in one region) that both causes replication
> and is maintained by it, all contained in a local area that maintains its
> boundary (as in autopoeisis). All that's missing is a packet of information
> that can evolve, and then this really would be life.

Thanks for the correction. I actually believed the two systems were
symbiotic, and I read through the equations twice to try to confirm
that belief, but somehow missed the presence of the "d" in the formula
for delta_b. (-:

[Scott Richmond]

So I've been plugging away at these for a few days now. Not much in the way of progress. OpenCL programming is a lot harder than I thought it'd be. I think part of my problem is that I think I'm looking at highly optimised kernel code and having a hard time unwrapping it all.

For example, lets take the Heat diffusion formula. That is simple enough. I think I get how that works. However I'm still struggling to make a second chemical that the first chemical will use to enforce a 'wall' or boundary condition. I got far enough that the second chemical was able to define areas not to diffuse 'heat' into, but unfortunately created weird artifacts such as the right side of the walls bleeding out and consuming the environment. Its hard to explain in words. The point is that my understanding is lacking.

A few questions:

1. Can I get an explanation of the float4's? [x,y,z,w] - xyz is self explanatory I suppose. w is the value of the grid point at xyz correct?

2. The biggest problem for me by far is the laplacian alculation. In the 2 chemical heat diffusion I was trying to make above I tried to split out the laplacian a calculation and perform if(in_b.n[xyz] == 0) checks to see if there was a wall there for each neighbour. If there was a wall I didn't include that neighbour in the laplacian a calc. It half worked, as noted above. Its likely some small mistake there has caused the artifacts I see. I might paste the code when I get home.

3. Why laplacian as opposed to say a simple Average() calc or something? --> This is clearly a question based on my ignorance in math. Apologies. :/

4. My understanding of the kernel code is that it is run in parallel for each gridpoint. Can I perform a 2-step process? For example I want to make a simple 3D fluid simulation. Part of the method for doing this is first iterating over the whole grid and calculating the future state in another grid, then swapping the future state to the current state at the end. Sort of like a buffer. Not sure how I would do this as a kernel program. Ideas? Advice?

[Tim Hutton]

For now it would be best to stick with a formula rule. float4's are just for speed (we process 4 neighboring cells at once) and we can ignore that for now.

Take a look at heat_equation_interpolation.vti. There we use a second chemical to limit the heat spread - turning it off in certain regions but fixing the temperature there. Maybe you can adapt that formula to do what you want?