-
-
Notifications
You must be signed in to change notification settings - Fork 202
-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Magnus and other linear operator solvers #90
Comments
For those curious, we already have partial linear methods implemented: so actually the infrastructure for doing all of this is already in there. Just the specific |
Does this mean we need to implement |
I'm developing the exponential integrators to default to https://github.com/JuliaApproximation/SpectralTimeStepping.jl/blob/master/src/timeevolution.jl#L55 it looks like a dense exponential is fine because the operator is only NxN where N is the number of coefficients, right? (the |
Yes, methods which do splitting have this stuff as part of the method. Essentially the splitting stuff will be like
Those look like they can be handled by the callbacks. You'll need to save to observables to your own array though, but it wouldn't be difficult. That may be tutorial-worthy though.
Or save zero copies with a matrix-free version. Or alias the underlying matrices. I think this could be something left to the user.
Julia will actually do this automatically if the operator is set as This means I should probably make sure that the |
It seems many physicists have problems of the form
u' = A*u
andu' = A(t)*u
. ThisA
can be from a PDE discretization, oru' = H(t)*u
naturally shows up from Schrodinger's equation. In these cases, we need to exploit the linearity of the problem in order to do well.This can all use the
DiffEqOperator
path where a user defines aDiffEqOperator
as their function. This contains anupdate_coefficients!(A,t,u)
function as well for handling time and state dependence. Then there are different things to tackle here. For one, we can make the stiff solvers "linear-aware". This can be done by, whenever we would be solving a nonlinear equation using a Newton method, instead do anIn the
#Linear Solve
part, it will just callupdate_coefficients!(A,t,u)
and then\
, so whatever overrides the user gives for how the matrix updates in time and whatever override for how the solving is supposed to take place will be used. (@shivin9 this is why the interface matching is important here)This will make things like
Trapezoid
automatically beCrankNicholson
, and will be very useful with things like BDF methods and ApproxFun. In addition, we can pull some inspiration from @jagot for Magnus integrators.http://iopscience.iop.org/article/10.1088/1367-2630/14/10/105008
Using the split operators interface we can also do things on
A + B(t)
both linear operators. But I don't know of algorithms directly on that, but technically the definition already exists.The
DiffEqOperator
will have a matrix-free pretty soon which closely matches that of LinearMaps.jl, but theDiffEqOperator
interface definesexpm
andexpmv
on the operator itself:https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/diffeq_operator.jl#L27
This means that the matrix-free versions will allow an optional method for directly defining
expmv
(and the array versions will get a quick upgrade to allow for direct definitions ofexpm
andexpmv
if someone has a use for it). This solves @jagot's problem since he wanted to use things liketo speed up the integrator by putting that definition in manually, and that interface would allow doing so.
DiffEqApproxFun.jl will get a special
AbstractDiffEqOperator
defined from ApproxFuns, which will define a linear operator onFun
types via ApproxFun operators. Even nonlinear ApproxFun operators can take this route because then it'll make it use the specialized ApproxFun Newton solver. What's interesting here is that DiffEq will be calling\
on the operator, so we can specialize the operator to hold the boundary conditions as well to do things likechop(Operator\[bcs;u],tol)
. With the type check above, this will convert the nonlinear parts on ApproxFuns to be just like SpectralTimeStepping.jl which is exactly what we needed @dlfivefifty.As for making it easy to solve finite difference PDEs, we have a library we are building which will automatically generate the linear operators from arbitrary order and derivative order PDE discretizations via Fornburg's algorithm:
https://github.com/JuliaDiffEq/PDEOperators.jl
This is all almost compatible with the full interface and will include things like time dependent BCs to make really good test cases for
u' = A(t)*u
.Things I don't know about: @jagot
What do you mean by this?
The text was updated successfully, but these errors were encountered: