lschuetze
commented
3 years ago I see what you mean. But the problem could be that the DSL is not executable by itself and there is the gap between the DSL and the generated code.
I could imagine that one could have means for generating "fast prototype code" that could help in tuning parameters (there is a paper currently under review for parameter tuning in OpenFPM).
It would also be interesting if one could find a way to define different discretization methods, different methods to solve PDEs for a given problem. For example, for prototyping the vortex methods can solve ∆v = −∇×ω for v on the mesh using a multigrid solver while if you want later on an exact solution you just turn it into a FFT solver.
Having watched some of the video lessons on OpenFPM, it came to my mind that setting up and working with an according toolchain is cumbersome. In the future, one should focus more on the 'E' in OpenPME, meaning that major obstacles for novice users can be overcome by having OpenFPM in the loop as a service. Based on the service, users can play with their simulations' prototypes, getting feedback quicker without copying generated artifacts from here to there. An important aspect here to consider is how to debug a simulation before deploying it on a cluster. One may have a simple integrated visualisation based on a kind of poor man's Paraview. One may even configure domains, ghosts and boundary conditions graphically and generate the code from there.
Of course these aspects are somewhat different from the goal to having a DSL from which you can generated highly-opimized client code. However, it seems to me that focussing on the optimization/code-generation aspects only will not bring you any further. But looking into the 'E' in OpenPME will open up much more opportunities in diverse directions. This would then also include optimizations because the 'E' will help to discover them.