Moving over from a DiscreteSpace representation of the domain to DiscretizedVariable equations

[xtalax]

trafficstars

Moving towards implementing a DiscretizedVariable with a smart recursive getindex and custom dict based indexing like Dict([x=>i, z=>k]) would allow for sampling whole expressions at once, and much greater flexibility, especially for mixed argument equations. Could contain also automatic interpolations and different underlying grid types per variable, helping with keeping grid types flexible and enabling staggered grids.

This would implement both the Array and Sym interfaces, allowing discrete equations that can be indexed into to give the equation at each interior point. This avoids the current need to wrap arguments to derivatives in a separate variable, and makes the rules much more comprehensible as well as allowing future extensibility i.e. #32.

Derivatives become the demarcation between different types of sampling and become a custom subtype of DiscretizedVariable, with special subtypes for Nonlinear laplacian/spherical and other types of derivatives with special handling.

There would be a step that recognises elements of an equation and replaces these with rules, creating a DiscretizedEquation and then the resulting equation is simply indexed into to generate the interior/BCs.

Is this a good idea? How much work is it to implement the Sym interface?

[xtalax]

@ChrisRackauckas @tinosulzer

[ChrisRackauckas]

@shashi for thoughts. This sounds interesting. I wonder how it would map to the coming stencil interfaces though.

[xtalax]

I think the stencil interfaces could go in the getindex for the derivatives, right?

[ChrisRackauckas]

yes exactly

[xtalax]

Periodicity and whether parameters join to others as in #32 can go in type info, can also have dependant variables that connect up in this way, reliance on dicts can be removed.

Also decouples variables from their grid type, and makes implementing new schemes much easier to reason about - becomes a problem of filling out the dispatch grid.

Rulegen would only need to happen once, which may lead to better performance. Having all analysis of the system happen in a separate step also makes it easier to sanity check the system.

This is a significant rewrite, but the amount that it eases reasoning about and working with the code base will likely pay dividends when moving to implementing more exotic grids and schemes as well as making the whole system cleaner. Will likely speed up future extensions. It fits the shape of the problem much better.

[xtalax]

Note to self, create a broadcast array wrapper type that broadcasts down operations on itself to handle substitution.