Making ISAAC way more generic and universal using even more templates

[theZiz]

At the moment ISAAC is "only" suitable to render gas and iso raycastings of 3D volumes described as a couple of disjunct cubiods distributed over the computation nodes. However there are way more ways to render 3D fields, more ways of 3D volume adresses like tetrahedron meshes or even 2D simulation data, not suitable to be converted to a 3D volume with it's own ways of rendering like a 40,000 x 40,000 scalar field per gpu. This needs a whole knew approach of live visualization.

So imo ISAAC should put

• the dimension of the data,
• the access pattern of the data and
• the render algorithms (depending on the dimension)

to own functors, integrated as template parameters as it is now happening with the render controller and compositor especially for stereographic rendering.
For the last one an mpl::list probably makes sense and to choose at runtime which of the preselected rendering algorithms to use - like now with the choice between iso surface and glowing gas rendering. Unfortunately I still doubt, that a rendering selection per source works with the ISAAC approach.
The template parameters can also implement constant atributes for metaprogramming, stating that the volumes don't need to be disjunct at all, which is e.g. not needed for iso surfaces when a z-buffer is used. With this one of the biggest disadvantages of ISAAC would vanish - at least for some renderings - without the need to think about sending data over network until the data is disjunct.

In the very end ISAAC should be some kind of compile time construction kit to get the most fitting visualization for every simulation with an easy way to extened the template implementations for new needs of simulations.

[ax3l]

Since this is a great future labeled issue, let me give you some examples that would make wonderful use cases:

• An interesting use case could also be a transformation of (multiple) 2D fields that "assume a certain symmetry in 3D" into a live-rendered 3D image as done in CALDER-Circ or FBPIC (see: doi:10.1016/j.jcp.2008.11.017). The back-to-3D-transformation is shown by this sum:

m+1 is the number of 2D fields for the scalar field E_z to take into account ("modes") and theta is a variable we have to render from 0 to 2pi during the back-transformation.

• A simpler "cylindrical" symmetry would be with m=0 which is only the first term E_{z,0} (it is independent of theta: "walking" around the cylinder with a fixed radius always gives the same value in "cylindrical" symmetry).
• And as we know from 2D3V PIC simulations, an other symmetry assumption would be to "clone" the simulation simply into the third dimension ("infinite wire-like cells").
• P.S.: a 1D3V PIC simulation would be spherical geometry that only changes in r but is constant in all theta/phi changes :)