Test v1.9

[utkarsh530]

@ChrisRackauckas I think Linearsolve.jl caused a breaking change here: https://buildkite.com/julialang/diffeqgpu-dot-jl/builds/510#01862989-6e8e-4cc1-aacb-c98e5d87438e/467-1011

[ChrisRackauckas]

@vpuri3

[vpuri3]

just got home. lemme take a look!

[vpuri3]

@utkarsh530 , in the failing test, https://github.com/SciML/DiffEqGPU.jl/blob/ec7d40987bd1e478eb64917bb9574fe29c3f09b6/test/ensemblegpuarray.jl#L71, DiffEqGPU is passing a size(W) = (3, 3, 10) LHS and _vec(linsolve_tmp) |> size = (30,) RHS array to LinearSolve. This leads to errors in the actual solve.

Example when I allow issquare = true in LinearSolve

julia> using LinearSolve; W = rand(3,3,10); b=rand(30); prob = LinearProblem(W,b); solve(prob)                                                                               [ Info: Precompiling LinearSolve [7ed4a6bd-45f5-4d41-b270-4a48e9bafcae]                
ERROR: Inconsistent problem size
Stacktrace:                                                                            
  [1] error(s::String)                                                                 
    @ Base ./error.jl:35                                                                 
[2] gmres!(solver::Krylov.GmresSolver{Float64, Float64, Vector{Float64}}, A::Array{Float64, 3}, b::Vector{Float64}; M::LinearAlgebra.UniformScaling{Bool}, N::LinearAlgebra.
UniformScaling{Bool}, ldiv::Bool, restart::Bool, reorthogonalization::Bool, atol::Float
64, rtol::Float64, itmax::Int64, verbose::Int64, history::Bool, callback::Krylov.var"#159#161", iostream::Core.CoreSTDOUT)                                                    
    @ Krylov ~/.julia/packages/Krylov/0FaHW/src/gmres.jl:108
  [3] #solve!#69                                                                       

and when I set issquare = false,

julia> using LinearSolve; W = rand(3,3,10); b=rand(30); prob = LinearProblem(W,b); solve(prob)                                                                                [ Info: Precompiling LinearSolve [7ed4a6bd-45f5-4d41-b270-4a48e9bafcae]                
ERROR: MethodError: Cannot `convert` an object of type                                   
    Array{Float64, 3} to an object of type                                                
    AbstractMatrix                                                                       
Closest candidates are:                                                                
  convert(::Type{AbstractMatrix}, ::SciMLOperators.ComposedOperator) at ~/.julia/packag
es/SciMLOperators/q1Otc/src/basic.jl:493                                                 convert(::Type{AbstractMatrix}, ::SciMLOperators.ScaledOperator) at ~/.julia/packages/SciMLOperators/q1Otc/src/basic.jl:217                                                 
  convert(::Type{AbstractMatrix}, ::SciMLOperators.IdentityOperator{N}) where N at ~/.julia/packages/SciMLOperators/q1Otc/src/basic.jl:15                                                                                      
Stacktrace:                                                                            
 [1] init_cacheval(alg::QRFactorization{LinearAlgebra.NoPivot}, A::Array{Float64, 3}, b
::Vector{Float64}, u::Vector{Float64}, Pl::SciMLOperators.IdentityOperator{3}, Pr::SciMLOperators.IdentityOperator{3}, maxiters::Int64, abstol::Float64, reltol::Float64, verb
ose::Bool, assumptions::LinearSolve.OperatorAssumptions{false})                        
   @ LinearSolve ~/.julia/dev/LinearSolve/src/factorization.jl:215

[utkarsh530]

It uses the special linear solver here: https://github.com/SciML/DiffEqGPU.jl/blob/ec7d40987bd1e478eb64917bb9574fe29c3f09b6/src/DiffEqGPU.jl#L728

[vpuri3]

ok, then https://github.com/SciML/SciMLOperators.jl/pull/149 should this issue.