an object should be constructed on which .solve() can be called that writes the solution into p. This would be the primary goal. Besides that, we should be able to construct block matrices to perform a combined solved of multiple transport equations p and U.
Proposed method
When dealing with parsing PDE with a DSL, it might be beneficial to parse the equation into an AST and solve the equation lazily. Hence, in our concrete example, we would first get a list of tokens. These tokens are not performing any substantial work besides being initialized. (I suspect that there are frameworks in existence which can do exactly that.). Next, we could run an optimiser step
over our tokens in order to fuse operations which are commonly performed together (e.g. ddt(U) + div (phi, U) ) in to a single kernel.
Some modifications to allow block matrices
Note: these ideas are up for debate, but I want to start some discussion.
In order to allow block coupled solver we need some mechanism to add equations to an existing equation set. One way would be to let the runTime handle the equations. A basic implementation would look like this:
On the call to runTime.solve() again first the optimiser would call fused kernels, assemble the matrix and solve the equation. I think this approach would also for more flexibility in several ways:
One could implement splitting procedures (if one desires) like PISO, SIMPLE, etc without hardcoding it in the application solver
It should allow for simpler implementing of time integration methods like RK4
This PR discusses fundamental ideas and requirements around a DSL parser architecture
Goals
Starting from code snipped like this
an object should be constructed on which
.solve()can be called that writes the solution intop. This would be the primary goal. Besides that, we should be able to construct block matrices to perform a combined solved of multiple transport equationspandU.Proposed method
When dealing with parsing PDE with a DSL, it might be beneficial to parse the equation into an AST and solve the equation lazily. Hence, in our concrete example, we would first get a list of tokens. These tokens are not performing any substantial work besides being initialized. (I suspect that there are frameworks in existence which can do exactly that.). Next, we could run an optimiser step over our tokens in order to fuse operations which are commonly performed together
(e.g. ddt(U) + div (phi, U) )in to a single kernel.Some modifications to allow block matrices
Note: these ideas are up for debate, but I want to start some discussion.
In order to allow block coupled solver we need some mechanism to add equations to an existing equation set. One way would be to let the runTime handle the equations. A basic implementation would look like this:
On the call to
runTime.solve()again first the optimiser would call fused kernels, assemble the matrix and solve the equation. I think this approach would also for more flexibility in several ways: