Integrate with time stepping codes

[dlfivefifty]

This should be a home for integrating ApproxFun with standard time-stepping codes, e.g.:

https://github.com/JuliaDiffEq/ODE.jl
https://github.com/luchr/ODEInterface.jl

This follows up on conversations at TU Munich with @luchr and @al-Khwarizmi, and a discourse discussion

https://discourse.julialang.org/t/pros-cons-of-approxfun/396/10

with @ChrisRackauckas.

[ChrisRackauckas]

Note that if you just target the DiffEq common interface, the same code will work for DifferentialEquations.jl, Sundials.jl, ODEInterface.jl, and ODE.jl. That's why I'm suggesting doing that.

[ChrisRackauckas]

All that would be required is that you'd have to be able to build a Problem type

https://juliadiffeq.github.io/DiffEqDocs.jl/latest/types/ode_types.html

If there's a function that builds the problem from an ApproxFun function, then it should all just work.

[dlfivefifty]

Ah OK. Note that the code here is derelict, and is of the variety of "discretize in time, ∞-dimensional in space" where your previous request was the more traditional pseudo-spectral approach of "∞-dimensional in time, discretize in space".

I think the latter approach of "∞-dimensional in time, discretize in space" is the right way to go, as it means nothing special has to be done to DiffEq.

[dlfivefifty]

For periodic problems it should be really easy.

How do you support constraints? For example, with a Dirichlet heat equation

$$u_t = u_{xx}, u(t,-1) = u(t,1) = 0$$

It's necessary that we constrain the value at ±1.

[dlfivefifty]

Also, is it necessary that u0 is an AbstractArray? Maybe a more elegant approach is to allow u0 to be a Fun, and as long as the time stepper is written in Julia, it should work.

[ChrisRackauckas]

Also, is it necessary that u0 is an AbstractArray?

That can be relaxed. Will a Fun index like an array?

[dlfivefifty]

No. Why would you need indexing like an array?

On 18 Nov. 2016, at 3:16 pm, Christopher Rackauckas notifications@github.com wrote:

Also, is it necessary that u0 is an AbstractArray?

That can be relaxed. Will a Fun index like an array?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #1 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABLDqZVgZxJx9KmhlBTx7ZuYDx-kv1nvks5q_SaCgaJpZM4K2GeC.

[dlfivefifty]

Let me rephrase that. a vector-valued Fun behaves like a vector:

f=Fun(x->[exp(x);sin(x)],[-1,1])
f[1]   # is Fun(exp,[-1,1])
f[2]  # is Fun(sin,[-1,1])

A scalar-valued Fun doesn't at the moment support indexing, but f[1] could return f.

[ChrisRackauckas]

For the update steps which do a linear combination on the partial steps, like in a Runge-Kutta method. For example, say we took two partial RK steps and stored them in k[1] and k[2], the next step would compute something like:

for i in eachindex(u)
  tmp[i] = a31*k[1][i] + a32*k[2][i]
end

Is it better than to treat a Fun like a scalar?

[ChrisRackauckas]

Well here's the big question: is a Fun mutable? Is it something that you'd update in-place?

[dlfivefifty]

Yes, a Fun should be treated like a scalar. As I understand it, the following code should work to solve heat equation with periodic boundary conditions for t in [0,1] if everything is designed correctly:

u0=Fun(θ->cos(cos(θ-0.1)),PeriodicInterval())
prob = ODEProblem((t,u) -> u'',u0,(0,1))   # ' is overriden for a Fun to mean derivative

(In practice, there should be a chop to make sure the length doesn't blow up, but that's a secondary consideration.)

[dlfivefifty]

Fun is immutable, but for no particular reason.

[dlfivefifty]

(My policy is to always use immutable to force me to think before I change to type.)

[ChrisRackauckas]

I think that immutable vs mutable is a better way of making the distinction. The reason is because we accept two different kind of functions: du = f(t,u) and f(t,u,du) which updates du in-place. The first doesn't require mutability. It seems like it should all work out if the types turn out all right. I don't know if this'll work with Sundials/ODEInterface though, I'm pretty sure they need arrays of Float64.

[dlfivefifty]

I think it's better to leave it immutable in this context: the number of coefficients of a Fun can change with each time step, and so it's hard to see off the shelf code handling this.