Switch to LevyArea.jl

[frankschae]

See #458
https://github.com/stochastics-uni-luebeck/LevyArea.jl https://arxiv.org/abs/2201.08424

To do:

• [x] Need to check AD compatibility [ see https://github.com/stochastics-uni-luebeck/LevyArea.jl/issues/6 ]
• [x] Update defaults [defaults to using LevyArea, allows for selecting specific routine, still contains separate implementations for diagonal and commutative noise which probably should be handled in a follow-up PR.]
• [x] Update tests [no path-wise convergence tests]
• [x] Update citations [ docs should be updated once this is merged.]

[ChrisRackauckas]

For strong convergence (and adaptivity) we would have to come up with a scheme so that we could easily pullback the Brownian paths. In the diagonal and commutative cases this is easy because it is done with the Brownian bridge, and the diagonal 1.5 case can be handled with a psuedo-Brownian process because the iterated integral approximation turns out to just be essentially two Brownian processes. I don't know what would have to happen with the non-commutative case though since it takes n random numbers?

[frankschae]

The test failures (StochasticDelayDiffEq/SROCKC2) look unrelated to me.

[fkastner]

For strong convergence (and adaptivity) we would have to come up with a scheme so that we could easily pullback the Brownian paths.

What exactly do you mean by pullback here?

Re adaptivity: I'm fairly confident to say that you can't use the Levy area in an adaptive scheme that requires the rejection of steps. We thought a bit about that, but it would require some new ideas or a completely new scheme for the Levy area approximation.

[fkastner]

Is the distinction between in-place and out-of-place still necessary for the iterated integrals? Especially since LevyArea.jl currently doesn't provide that distinction either. There is no reason why the in-place-ness of the iterated integral computations has to be coupled to the in-place-ness of the problem itself, or am I missing something here?

[frankschae]

I would say we could either remove the inplaceness completely, i.e., by removing it also from all SDE solvers https://github.com/SciML/StochasticDiffEq.jl/blob/c802f6ec6a8cb06e0d5797fc7605d7cb85fb9e25/src/perform_step/low_order.jl#L449 (For problems with mutating functions, the iip formulations were originally used to avoid allocations -- this doesn't work for the methods from LevyArea.jl.) Alternatively, we can use this wrapper that offers no computational advantage but allows us to remove allocations for the other cases (IICommutative()) in principle.

[ChrisRackauckas]

What the reason for not having a preallocated form in LevyArea.jl? I presume the allocation here would impact at least multithreaded performance.

[ChrisRackauckas]

The SDDE test is just noisy. I need to fix that when I get back.

[ChrisRackauckas]

Continuing the discussion on fully inplace in https://github.com/stochastics-uni-luebeck/LevyArea.jl/issues/7 . While it could hit performance, for now we can probably just skip it.

[fkastner]

Alternatively, we can use this wrapper that offers no computational advantage but allows us to remove allocations for the other cases (IICommutative()) in principle.

Yes, that was my suggestion. Basically remove the out-of-place functions. It should be possible to use in-place Levy area approximations (no matter how much of it is in-place) even for out-of-place problems, shouldn't it?

[ChrisRackauckas]

out of place would still be required for some forms of automatic differentiation and for use cases with immutable arrays and static arrays. So that still would have a place in the grant scheme of things.