Add the median to EnsembleSummary and adjust the plot recipe

[nathanaelbosch]

Fixes #132

The following script can be used for a before/after comparison:

using OrdinaryDiffEq, Plots

logistic(du, u, p, t) = @. du = p * u * (1 - u)
prob = ODEProblem(logistic, [1e-2], (0.0, 2.5), [3.0])
prob_func(prob, i, repeat) = i < 100 ? remake(prob, u0=[0.9]) : remake(prob, u0=[1e-2 + 0.001*randn()])
eprob = EnsembleProblem(prob, prob_func=prob_func)
esol = solve(eprob, Tsit5(), trajectories=1000)
esum = EnsembleSummary(esol, 0.0:0.01:2.5, quantiles=[0.1, 0.9])
plot(esum)

Now, the plot recipe plots the median and quantiles and the resulting plot becomes more easily interpretable.

I did not add any new tests or adjust version numbers, so please let me know what should be done in these regards.

[ChrisRackauckas]

Add a test for the median call?

[codecov]

Codecov Report

Merging #134 (5e9c889) into master (176e987) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##           master    #134      +/-   ##
=========================================
- Coverage    6.89%   6.88%   -0.02%     
=========================================
  Files          40      40              
  Lines        2959    2964       +5     
=========================================
  Hits          204     204              
- Misses       2755    2760       +5     

Impacted Files	Coverage Δ
src/ensemble/ensemble_analysis.jl	36.40% <0.00%> (-0.33%)	⬇️
src/ensemble/ensemble_solutions.jl	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 176e987...5e9c889. Read the comment docs.

[nathanaelbosch]

Add a test for the median call?

I'm not quite sure what test you're suggesting. Checking that timestep_median and timepoint_median return the correct values for a simple example? Which would probably mean adding an actual EnsembleProblem solve to the tests?

EDIT: I just found test/downstream/ensemble_zero_length.jl, it seems like I could add a line there.

[ChrisRackauckas]

@chriselrod Looks like LabelledArrays conversions may have led to a downstream issue?

[chriselrod]

Another LoopVectorization + ArrayInterface 4 here: https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:56
@KristofferC any idea what could be going on here, or how to diagnose, why we seemingly keep getting ArrayInterface 4 + LoopVectorization, even though LoopVectorization's compat bounds exclude ArrayInterface 4? https://github.com/JuliaSIMD/LoopVectorization.jl/blob/b0ba0370926a7288a270b4a0a19ab2990be83c1c/Project.toml#L28
This has been causing test failures for weeks; LoopVectorization is incompatible with ArrayInterface 4, and using them together will result in the error messages listed there.

I'm not sure if it's a Pkg bug, because we've never really gotten a reproducer/had someone share a problematic environment. Whenever anyone reports the error, as soon as they add one of the packages to report the status, Pkg re-resolves, installs a compatible version, and then the problem goes away.

[chriselrod]

@ChrisRackauckas, I guess you were talking about this

LabelledArrays Tests: Error During Test at /home/runner/.julia/packages/SafeTestsets/A83XK/src/SafeTestsets.jl:25
  Got exception outside of a @test
  LoadError: type Array has no field x
  Stacktrace:
    [1] getproperty(x::Vector{Float64}, f::Symbol)
      @ Base ./Base.jl:33
    [2] f1(du::Vector{Float64}, u::LabelledArrays.LArray{Float64, 1, Vector{Float64}, (x = 1:4, y = 5:8)}, p::Vector{Float64}, t::Float64)
      @ Main.##282 ~/work/SciMLBase.jl/SciMLBase.jl/downstream/test/downstream/labelledarrays.jl:20
    [3] (::SciMLBase.ODEFunction{true, typeof(Main.##282.f1), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing})(::Vector{Float64}, ::Vararg{Any, N} where N)
      @ SciMLBase ~/work/SciMLBase.jl/SciMLBase.jl/src/scimlfunctions.jl:334

du is a Vector and u is a LabelledArray.

The PR added a method:

julia> using LabelledArrays

julia> A = @LArray [1,2,3] (:a,:b,:c)
3-element LArray{Int64, 1, Vector{Int64}, (:a, :b, :c)}:
 :a => 1
 :b => 2
 :c => 3

julia> convert(AbstractVector{Float64}, A)
3-element LArray{Float64, 1, Vector{Float64}, (:a, :b, :c)}:
 :a => 1.0
 :b => 2.0
 :c => 3.0

Even though this is in LabelledArrays tests, perhaps u was supposed to be a vector?
But it'd take more digging to find out what went wrong. I may be able to take a look tomorrow.

[KristofferC]

Another LoopVectorization + ArrayInterface 4 here: https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:56

Not really. In the status output here: https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:36 there is no LoopVectorization present which means that ArrayInterface is free to be whatever it wants. It is only after the test start running and the test specific dependencies are installed that LoopVectorization is present: https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:336 but then ArrayInterface is downgraded: https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:265.

So at no point do you have both LoopVectorization and ArrayInterface v4 in a project.

[chriselrod]

So at no point do you have both LoopVectorization and ArrayInterface v4 in a project.

The error LoopVectorization throws is one we'd get if it were hypothetically paired with ArrayInterface 4, but not if it were paired with ArrayInterface 3.
ArrayInterface 3 returned nothings where ArrayInterface 4 returns missing.

I do not know how or why this is, but it keeps causing test failures.

It is possible that another package is guilty of having made the switch from returning nothing to returning missing, while allowing compatibility with both 3 or 4.

[KristofferC]

https://github.com/SciML/SciMLBase.jl/runs/5083436845?check_suite_focus=true#step:6:525

The checkmark is in yellow. And in the bottom of the log we see:

4 dependencies precompiled but different versions are currently loaded. Restart julia to access the new versions
591

So, it seems that one version of ArrayInterface is loaded already. But Pkg.test should make a new process so I don't see why that would matter...

[KristofferC]

I guess it is this stuff:

SciMLBase.jl/test/runtests.jl

Lines 12 to 16 in 176e987

	function activate_downstream_env()
	Pkg.activate("downstream")
	Pkg.develop(PackageSpec(path=dirname(@__DIR__)))
	Pkg.instantiate()
	end

. You probably need to do that in a separate process. The new versions resolved from that will not be available in a session that has already loaded those packages at some other version.