Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Issue with OrdinaryDiffEq.jl when using an ArrayPartition of Arrays of StaticArrays

Open
#212 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
julia
Domain
tooling

Research direction

Start by running the supplied MWE with StaticArrays, StructArrays, RecursiveArrayTools, and OrdinaryDiffEq. Inspect src/array_partition.jl around the copyto! implementation at lines 327-329, along with the reported eltype behavior and StructArrays conversion stacktrace. Done means the MWE no longer raises the Float64-to-SVector conversion MethodError.

Written by the indexing model from the issue text.

Description

OrdinaryDiffEq.jl has an issue with ArrayPartitions constructed from nested arrays of StaticArrays. The following MWE

using StaticArrays, StructArrays
using RecursiveArrayTools
using OrdinaryDiffEq

u1 = StructArray{SVector{2, Float64}}(ntuple(x -> x * ones(10), 2))
u2 = deepcopy(u1)
u = ArrayPartition(u1, u2)

function rhs!(du, u, p, t) 
    du .= u
end
prob = ODEProblem(rhs!, u, (0, 1.0))
sol = solve(prob, Tsit5())

yields the stacktrace

ERROR: MethodError: Cannot `convert` an object of type Float64 to an object of type SVector{2, Float64}
Closest candidates are:
  convert(::Type{SA}, ::Tuple) where SA<:StaticArray at ~/.julia/packages/StaticArrays/0T5rI/src/convert.jl:171
  convert(::Type{SA}, ::SA) where SA<:StaticArray at ~/.julia/packages/StaticArrays/0T5rI/src/convert.jl:170
  convert(::Type{SA}, ::StaticArray{S}) where {SA<:StaticArray, S<:Tuple} at ~/.julia/packages/StaticArrays/0T5rI/src/convert.jl:164
  ...
Stacktrace:
  [1] maybe_convert_elt(#unused#::Type{SVector{2, Float64}}, vals::Float64)
    @ StructArrays ~/.julia/packages/StructArrays/rICDm/src/utils.jl:197
  [2] setindex!
    @ ~/.julia/packages/StructArrays/rICDm/src/structarray.jl:363 [inlined]
  [3] macro expansion
    @ ./broadcast.jl:961 [inlined]
  [4] macro expansion
    @ ./simdloop.jl:77 [inlined]
  [5] copyto!
    @ ./broadcast.jl:960 [inlined]
  [6] copyto!
    @ ./broadcast.jl:913 [inlined]
  [7] f
    @ ~/.julia/packages/RecursiveArrayTools/YoTgv/src/array_partition.jl:327 [inlined]
  [8] ntuple
    @ ./ntuple.jl:49 [inlined]
  [9] copyto!
    @ ~/.julia/packages/RecursiveArrayTools/YoTgv/src/array_partition.jl:329 [inlined]
 [10] materialize!
    @ ./broadcast.jl:871 [inlined]
 [11] materialize!
    @ ./broadcast.jl:868 [inlined]
 [12] fast_materialize!
    @ ~/.julia/packages/FastBroadcast/fkwMa/src/FastBroadcast.jl:47 [inlined]
 [13] ode_determine_initdt(u0::ArrayPartition{Float64, Tuple{StructVector{SVector{2, Float64}, Tuple{Vector{Float64}, ....

I'm not sure but this seems to be related to the fact that eltype of ArrayPartitions of AbstractArray{<:StaticArray{N,T}} is T rather than StaticArray{N,T}.

Dominant language
Julia
Stars
233
Forks
76
Avg merge
5h 33m
Merged PRs (30d)
11

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SciML/RecursiveArrayTools.jl

All issues in SciML/RecursiveArrayTools.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.