Short term goals

[ChrisRackauckas]

@MSeeker1340 @jlperla we should be clear on what to create now one thing for sure is that we should make it much easier to grab the N x N-2 stencils for the discretizations so the operators should have a no-bc mode which returns this stencil but I still think it would be useful to directly build the boundary-incorporated operators which is L*Q instead of just the L (edited) this gives you a square operator which is nice and clean to work with The issue with the previous design is that we didn't have strict conventions and a clear way to derive each of the possible boundary-incorporated operators from these discussions it's pretty clear what to do now though Just take the Q from the polynomial that is order matching or one order less and then compose the two operations non-zero Dirichlet needs to be made to have an affine part, and this should have a printout somehow Neumann, especially at higher order, then needs to be changed so that way it's always using a polynomial that extrapolates to one point on the boundary. and Robin is just those together periodic only seems to be well-defined on the half-points, so make that the half-point discretization and make sure that gets documented well then if we fix the conventions in the tests, all current tests should pass That handles all of @Jesse Perla’s cases which do not have jump operators (which is what I mean by linear continuous operators) so now for jump operators we just need to give the tools for handling the Q nicely it should probably just be reflecting and absorbing for now, and specify the number of spaces beyond the boundary necessary and the actual jump operators are just shifted I off the diagonal, for now. (edited) next step is irregular grids the first part, linear continuous operators, should map right over using Fornberg. It should just dispatch on whether dx is a scalar or AbstractVector, and then the implementation needs an array of stencils but other than that the BC handling is the same (just choose interpolation polynomial and etc) for the jump operators, they should then get an added argument for degree and jumps to non-grid points should just use the interpolation polynomial of that degree I am not sure we'll get that far, but it's something to keep in mind I think that would cover everything @Jesse Perla is looking for? Let me copy this into an issue: it ended up longer than I thought

[jlperla]

I think the first short-term goal is to finalize the math on this so we know exactly what we are building towards and finalize notation to help us use the same language. That is why I posted https://github.com/JuliaDiffEq/PDERoadmap/issues/29

In the meantime, I am going to very explicit and type up a list of differential operators that I want to solve between now and October (I will prioritize). We can use those as a test-case for the math.

Then if we design the interface which makes those cases possible, we can design the underlying mechanics of combining the boundary conditions, etc. In all cases, I am just interested in having it spit out a square M x M affine operator spitting out the

now one thing for sure is that we should make it much easier to grab the N x N-2 stencils for the discretizations

Just to be clear, these are not always M x (M+2) (please stick with the notation in the document to prevent errors in communicating) An obvious case is with I is only MxM and needs to be expanded when composed. Another is that if you are dealing with backwards differences you really only need to add one point at the bottom, etc. But those are relatively easy.

The bigger case is for jump diffusions. If it can jump M_E^- points backwards and M_E^+ points forwards, then the number of points is M_E = M_E^- + M_E^+ and the size of the extended space is M_bar = M + M_E. Take a look at the document for the notation, which was discussed back in May timeframe.

For me: it is absolutely essential that we design the interface to support jump operators (even if we don't implement them immediately). I need to use them in a paper where coding would commence in September.

[ChrisRackauckas]

I think we have come full circle. By developing an operator notation and by looking at its properties, we have now proven (or essentially proven, it's easy to write down the proof) that you can write each operator in a way that incorporates the boundary conditions separately, so we might as well do that to simplify everything computationally. It's not too difficult to write down periodic jump operators as a cyclic shift, or Dirichlet jump operators as a truncated shift. Neuman has the difficulty that it's the mod'd shift, and the non-zero Neuman is difficult to derive in a simple manner.

[jlperla]

I think we have come full circle. By developing an operator notation and by looking at its properties, we have now proven (or essentially proven, it's easy to write down the proof) that you can write each operator in a way that incorporates the boundary conditions separately,

I am not convinced of that at all. It may be true for homogenous boundary conditions, but I am not even sure if you can meaningfully write down a boundary condition without the composed operator in many circumstances.

If I am writing down some complicated absorbing barrier for a jump diffusion which payoffs in different states of where you land after a jump, how can you apply that sort of condition to the drift term separately?

[ChrisRackauckas]

Write it down in operator notation and simplify.