Change internals to Diffeq #191
Conversation
|
Re-running tests because the release that this needed is now in METADATA. Also, I just noticed that this doesn't do anything special for the single-trajectory Monte Carlo stuff, so I am not sure why tests pass there. Those jumps need to be |
|
Yeah maybe a good idea to not test on "latest" :P |
|
I ran the benchmarks. They look very promising.
And even though, as you said, this is not doing anything special for Monte Carlo approaches, it is also not slowing things down.
In the above, the orange line is your PR. There is a problem though, that I noticed while benchmarking. In the benchmarks, we use an b = FockBasis(9)
a = destroy(b)
at = create(b)
n = number(b)
tspan = [0:1.0:10;]
H = a + at
J = [a]
rates = [1.0]
Ψ₀ = coherentstate(b, 0)
tout, ρt = timeevolution.master(tspan, Ψ₀, H, J; rates=rates)
exp_n = real.(expect(n, ρt))the amount of points stored correspond to exp_n = Float64[]
fout(t, ρ) = push!(exp_n, real(expect(n, ρ)))
timeevolution.master(tspan, Ψ₀, H, J; rates=rates, fout=fout)results in an The build checks keep failing, because we still have support for Julia v0.5, for which your latest Callbacks is not available. We should probably drop support for v0.5 anyway. Edit: out = DiffEqCallbacks.SavedValues(Float64,typeof(fout(tspan[1], state)))in combination with the in-place push! used in the above example is the cause of the problem I think. |
Support for v0.5 is locked in METADATA. No packages can release new versions with v0.5. I'll go ahead and upgrade the build scripts. |
Oh, I forgot to mention that in the new version there is a breaking change that you no longer have to build arrays to |
|
Oh, I could have caught that... function fout(t, rho)
expect(op1, rho)
endis more intuitive than using Properly inferring the type of |
Yes, it would be the same to the user, but I would just use |
Codecov Report
@@ Coverage Diff @@
## master #191 +/- ##
=======================================
- Coverage 99.5% 99% -0.5%
=======================================
Files 32 32
Lines 2222 2215 -7
=======================================
- Hits 2211 2193 -18
- Misses 11 22 +11
Continue to review full report at Codecov.
|
|
I edited the inference to work without the |
|
I don't think the additional argument can break much. On the other hand, I don't know how much this instability will even affect things. So I think either way is fine. |
|
MCWF is fixed to now use the DiffEq callbacks. |
|
I think that's everything. DDEs/SDEs/etc. can be a separate PR. But this should be everything switched over to DiffEq internals, with the breaking changes that |
|
I ran the benchmarks on MCWF again. Looks like your final changes will give us quite a performance boost.
The green one here is your latest commit, the others are the same as before. So let's merge this beauty! |
This sets up the internals to use DiffEq. All of the tests pass. There is a breaking change in that the steady state parts now return the solution array (with saveat matching the giving timespan, so it's the same but includes the initial point). Other than that, nothing changes. This requires DiffEqCallbacks v0.7.0 which should be released shortly.
As for speed, benchmarks show that as setup it's roughly the same on very non-stiff problems. The previous integrator's
reltol=1e-7takes as much steps as this one'sreltol=1e-6, and with these the DiffEq one is ever so slightly faster. But true benchmarks should take into account error as well. The QO benchmarks should be run again like in #92 . Note that the current DiffEq infrusturcture takes a hit on very cheap problems due to Julia's keyword argument handling and lack of constant propogation, but those are both fixed in v0.7 so we'll get a free speedup when the next version of Julia is released.But, the DiffEq DP5 uses PI adaptive time stepping which will be more stable and by far more efficient on semi-stiff equations. And that's mostly the point. I wouldn't expect anything major on simple non-stiff equations like in the tests, but if you increase the stiffness of the PDE, then DiffEq allows a lot more options to handle stiff equations (whereas explicit Runge-Kutta methods simply fail). However, the option to pass integration algorithms to override the internal default is not part of this PR (but it would be very simple). Also, by changing
ODEProblemto things likeDDEProblemorSDEProblemthis (with different algorithm choices) will solve other types of differential equations as proposed in #164 .