PDERoadmap
PDERoadmap copied to clipboard
SciML
Support affine operators (with affine boundary values)?
In https://github.com/JuliaDiffEq/PDERoadmap/issues/4#issuecomment-412350446 , @dlfivefifty brings up the following PDE: B*u= c and u_t = L*u + f where B is a boundary operator, L is a linear operator, and c, f are constant terms.
Now, in the current design we are able to handle the boundary extrapolation with the affine c term (i.e., the Q operator in https://github.com/JuliaDiffEq/PDERoadmap/releases/download/v0.2/linear_operators_overview.pdf is affine and not linear.
But I don't think we wrote any examples, or did the math, doing the full RHS of L * u + f. Instead, we discretized the L subject to the affine boundary conditions, with the anticipation that the user would do the f forcing on their own.
Is there a way for us to handle the affine differential operators more directly? That is,
u_t = A u where A u = L * u + f is a composed affine, rather than linear operator?
@ChrisRackauckas @MSeeker1340 Any thoughts? If so, does the current math work with minimal changes?
I see that this was brought up in https://github.com/JuliaDiffEq/PDERoadmap/blob/master/linear_operators_overview.tex#L58 so worth investigating before we go to far down the implementation of the differential operators and the boundary conditions.
Is there a way for us to handle the affine differential operators more directly? That is, u_t = A u where A u = L * u + f is a composed affine, rather than linear operator?
Yes that's what the composed operator does, so that can be used. The reason that wasn't focused on was because it's usually very uninteresting: we want to specialize on affine ODEs directly via the phi functions, while nonlinear terms are more likely to show up in practice.
Forcing terms come up in immersed boundary methods, so should be supported down the line, but indeed nonlinear terms are more important.
@MSeeker1340 From discussions with @ChrisRackauckas it sounds like this makes sense to do at the same time as #29. Better to get the math all done correctly, and with consistent notation, before embarking on any code and examples.
Better to get the math all done correctly, and with consistent notation, before embarking on any code and examples.
About notation: I think the current one used in Section 1 ($Ax = A_Lx + A_b$) is good enough? The $L$ and $b$ subscript should be pretty clear at first glance and the use of subscripts avoid the issue of using up too many letters.
Again, $A_L$ and $A_b$ are convenient, conceptual entities and do not necessarily correspond to the actual implementation of affine operators (though storing them separately is the most straightforward way). For example, we may define affine operators not as a concrete type but as an interface, with methods to return either $A_L$ or $A_b$.
Agree entirely. Abstract interface in implementation, but the math is a little easier to follow if we don't need to keep around the constant and matrix around for all the algebra