Raise the level of abstraction

[svenkarol]

In its current state, the DSL looks more like an imperative particle programming language. While an imperative approach is powerful in terms of expressivenes, a DSL may not need to strive for this, i.e., supporting arbitrary simulations is not necessary. What one instead could do is to provide some interop with the library so that users can write C++ code embedded into the DSL or vice-versa.

The problem is that if the DSL gets conceptually close to an imperative programming language it will not add too much benefit over using OpenFPM directly, which already has some nice template-library abstractions inside.

[lschuetze]

The example LJ_paper/Lennard Jones already provides some abstractions to represent the interact/evolve inside a simulation to also allow more of a functional declarative approach to particle methods. The inclusion of arbitrary external datatypes is already thought of.

The current idea is to have a second DSL that allows to define where such an external datatype can be found (e.g., the header files) or the possibility to create a custom data type, define its interfaces and implement it with arbitrary C++. The idea of the interface definition is to use it for consistency checking in the models during code generation.

[svenkarol]

Ok, great! What are the external data types then used for, particle properties?

A functional style for the particle computations would be very nice. Currently, evolve and interact are side-effects on particles. Converting this into a functional style at least would be interesting w.r.t. function composition, although the side-effect will persist because of the computational model.

particles.asPairs().interact( (p, q) => { p.force += 24.0 * .. } ).asGrid().evolve( p => p.velocity += ... ) ;-)

[lschuetze]

Actually, I meant declarative approach. That is, there is the goal of just having to describe the interact and evolve formulae for the phenomenon to be modeled and in the simulation code to just define which particles interact on which properties. A data flow analysis should then select the correct formulae and all its dependent variables. For a functional style I think there are too many side effects (such as solvers solving equations on a grid etc) during each iteration.

The declarative approach would be an interesting feature for composition/reuse as one could write fragment simulations where properties to be simulated on could be templates. A complete simulation could be designed by instantiating these fragment. Once instantiated the actual formulae are selected and code can be generated.

The external data types could be used for custom property types. But maybe also custom data types are used for variables in the simulation which could be used here.