Objects can be created with any length and subdivided into discrete partitions. Length (lx,ly,lz) and partitioning (nx,ny,nz) are independent for each dimension. Objects can be initialized using a FLAT or GAUSSIAN method.

Five solvers are (mostly) implimented. Forward-Time Central-Space is implimented for all three dimensions. Crank Nicholson is implimented in 1D and 2D. The matrix and object storage/serialization code was designed before I understood exactly how Crank-Nicholson actually worked. As a result it is heavily optimized for FTCS (dimensionally independent lookups) and embarassingly slow at CN which needs memory contiguous matricies and vectors to really work at all. I have not implimented 3D Crank Nicholson because without rewriting my matrix and object data structures it would be too slow to even test for correctness.

Both FTCS and Crank Nicholson support adding an arbitrary time independent source term and both flat (with the option to specify a non-zero boundary value) and periodic where the boundary conditions wrap around.

Jacobi, Gauss-Seidel, and successive over-relaxation (SOR) solvers for 1D, 2D, and 3D were added at a later point. All three new solvers should work with periodic boundary conditions, non-cubic domains, and the constant source term but those features have not been extensively tested.

This is a simple command line utility that bootstraps the solver code and allows running the solver in small input tests. It has no external dependencies beyond the C 11 STL.

This is a more complicated simulation server that uses WebSocket to communicate with a command and visualization client running in a browser. The server accepts input in the form of a simple command language that allows specifying the simulation input parameters. Visualization output is performed either as a 2D plot (1D problems only) or as a 2D grayscale image. White represents hot, black cold.

The command language works as follows:

command:arg1=val1;arg2=val2;

trailing punctuation is always retained.

The commands recognized are simulate and cancel. Simulate will start a simulation on one of the processing threads. Cancel will signal the simulation thread to cancel the simulation the next time that processing thread checks in. Processing threads check in to test for canceling and deliver a simulation snapshot timestep at a specifiable interval. Simulator I/O is handled in one thread and there are a configurable number of simulation processing threads. Simulations are assigned to processing threads in FIFO order.

Arguments for the simulate command:

The client will operate on any modern browser with WebSocket support. This includes: Safari 5.0.1 iOS 4.2 FireFox 6 Chrome 6 IE10

On browsers with full RFC6455 support it will use binary websocket for drastically improved visualization performance. These browsers are: Chrome 16 FireFox 11

Building the server requires Boost and WebSocket (github.com/zaphoyd/websocketpp). If you have trouble building it let me know.

make CXX=g DEBUG=0 WEBSOCKETPP_PATH=/path/to/websocketpp/headers WEBSOCKETPP=/path/to/websocketpplib.a BOOST_INCLUDE_PATH=/path/to/boost/headers BOOST_LIB_PATH=/path/to/boost/libs

300x300 square simulated for 100 seconds

100x100x100 cube simulated for 10 seconds

100x100x100 cube simulated for 25 seconds

At higher dt FTCS blows up and is wildly inaccurate. At shorter simulation periods, FTCS is competitive. At longer time periods SOR pulls ahead drastically as FTCS is stuck on smaller timesteps.