Something is broken, perhaps NonlinearSolve?

Since two days something is broken:

        Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
Precompiling project...
  ✗ NonlinearSolveSpectralMethods
  ✗ NonlinearSolveSpectralMethods → NonlinearSolveSpectralMethodsForwardDiffExt
  ✗ NonlinearSolveQuasiNewton
  ✗ NonlinearSolveFirstOrder
  ✗ NonlinearSolveQuasiNewton → NonlinearSolveQuasiNewtonForwardDiffExt
  ✗ NonlinearSolve
  ✗ NonlinearSolve → NonlinearSolveNLsolveExt
  ✗ NonlinearSolve → NonlinearSolveSundialsExt
  ✗ VortexStepMethod
  ✗ ModelingToolkit
  ✗ OrdinaryDiffEqNonlinearSolve
  ✗ OrdinaryDiffEqSDIRK
  ✗ ModelingToolkit → MTKChainRulesCoreExt
  ✗ OrdinaryDiffEqBDF
  ✗ KiteModels
  372 dependencies successfully precompiled in 147 seconds. 22 already precompiled.
  2 dependencies had output during precompilation:
┌ LinearSolve
│   Downloading artifact: MKL
└  
┌ MKL_jll
│   Downloading artifact: IntelOpenMP
└  

The following 9 direct dependencies failed to precompile:

KiteModels 

Failed to precompile KiteModels [b94af626-7959-4878-9336-2adc27959007] to "/tmp/testdepot/compiled/v1.11/KiteModels/jl_HD6GJp".
ERROR: LoadError: TaskFailedException

    nested task error: MethodError: no method matching init(::SciMLBase.NonlinearProblem{Float64, false, Float64, SciMLBase.NonlinearFunction{false, SciMLBase.NoSpecialize, Any, Any, Any, Any, Any, Any, Any, Any, Any, Any, Any, Any, Any, Nothing, Any, Any, Any}, Base.Pairs{Symbol, Union{}, Tuple{}, @NamedTuple{}}, SciMLBase.StandardNonlinearProblem}, ::NonlinearSolveFirstOrder.GeneralizedFirstOrderAlgorithm{Missing, Missing, NonlinearSolveBase.NewtonDescent{Nothing}, Nothing, Nothing, Nothing, Val{false}}; abstol::Float64, verbose::Bool)
    The function `init` exists, but no method is defined for this combination of argument types.
    
    Closest candidates are:
      init(::SciMLBase.AbstractJumpProblem, ::Any...; kwargs...)
       @ DiffEqBase /tmp/testdepot/packages/DiffEqBase/p82Yh/src/solve.jl:54
      init(::SciMLBase.AbstractDEProblem, ::Any...; sensealg, u0, p, kwargs...)
       @ DiffEqBase /tmp/testdepot/packages/DiffEqBase/p82Yh/src/solve.jl:41
      init(::SciMLBase.LinearProblem, ::Any...; kwargs...)
       @ LinearSolve /tmp/testdepot/packages/LinearSolve/n9KK1/src/common.jl:111

You can nicely see when things start to fail here:

Last working run: Install KiteModels#main · OpenSourceAWE/AWEMeta.jl@fd7d444 · GitHub

First broken run:

The only difference I found so far is the version of SciMLOperators. Version 1.7.2 fails.

Update:
Adding this line solves the problem:

SciMLBase = "<2.115"

But this indicates a problem somewhere.

Interesting outcome. Is NonlinearSolveBase fixed to a version?

For the record, here’s what I think is involved. We have been on a mission to complete the “base splitting” project discussed in the 2024 roadmap. The “base splitting project” is the fact that NonlinearSolve.jl, Optimization.jl, etc. all arose pretty organically from DifferentialEquations.jl, which means they are interconnected in ways that don’t really make sense anymore. This month is ripping off the bandaid. I.e., NonlinearSolve.jl should not depend on DiffEqBase.jl but instead anything for the nonlinear solvers should be in NonlinearSolveBase.jl. Another big part of this is that an AbstractNonlinearProblem shouldn’t be an AbstractDEProblem (abstract differential equation), that only existed in SciMLBase because DiffEqBase’s high level solve handling was for AbstractDEProblem, so when NonlinearProblem was added… it was bolted into there… but now that’s it’s own whole library and that got its own Base etc. etc.

So with that background, we have recently removed the odd subtyping of NonlinearProblem in SciMLBase.jl, we removed the NonlinearProblem high level handling in DiffEqBase.jl, and that was moved to NonlinearSolve.jl. There are some fallbacks and stuff put in there but with this number of very deep changes to type hierarchies something must’ve happened, where there’s a version that’s off and you’re getting half of the update or something, and it’s not hitting a fallback.

Whatever it is, my guess is that if you update to ensure you have the latest NonlinearSolveBase.jl then you should be fine? That’s the first thing to try for getting up to date. My guess is that pulling back SciMLBase was required for the NonlinearProblem <: AbstractDEProblem, which was using the DiffEqBase solver setup code because you have an older NonlinearSolveBase.jl so it doesn’t exist there yet, and hence removing the subtyping makes it not catch the method that’s supposed to have been moved. It might be difficult to catch this exact set.

CC @jClugstor who has been helping with this change.

1 Like

This works:

name = "KiteModels"
uuid = "b94af626-7959-4878-9336-2adc27959007"
authors = ["Uwe Fechner <fechner@aenarete.eu> and contributors"]
version = "0.9.0"

[deps]
ADTypes = "47edcb42-4c32-4615-8424-f2b9edc5f35b"
AtmosphericModels = "c59cac55-771d-4f45-b14d-1c681463a295"
CodecXz = "ba30903b-d9e8-5048-a5ec-d1f5b0d4b47b"
Dierckx = "39dd38d3-220a-591b-8e3c-4c3a8c710a94"
DiffEqBase = "2b5f629d-d688-5b77-993f-72d75c75574e"
DiscretePIDs = "c1363496-6848-4723-8758-079b737f6baf"
DocStringExtensions = "ffbed154-4ef7-542d-bbb7-c09d3a79fcae"
Interpolations = "a98d9a8b-a2ab-59e6-89dd-64a1c18fca59"
KitePodModels = "9de5dc81-f971-414a-927b-652b2f41c539"
KiteUtils = "90980105-b163-44e5-ba9f-8b1c83bb0533"
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
LinearSolve = "7ed4a6bd-45f5-4d41-b270-4a48e9bafcae"
ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78"
NLSolversBase = "d41bc354-129a-5804-8e4c-c37616107c6c"
NLsolve = "2774e3e8-f4cf-5e23-947b-6d7e65073b56"
NonlinearSolve = "8913a72c-1f9b-4ce2-8d82-65094dcecaec"
OrdinaryDiffEqBDF = "6ad6398a-0878-4a85-9266-38940aa047c8"
OrdinaryDiffEqCore = "bbf590c4-e513-4bbe-9b18-05decba2e5d8"
OrdinaryDiffEqNonlinearSolve = "127b3ac7-2247-4354-8eb6-78cf4e7c58e8"
Parameters = "d96e819e-fc66-5662-9728-84c9c7592b0a"
Pkg = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f"
PrecompileTools = "aea7be01-6a6a-4083-8856-8a6e6704d82a"
REPL = "3fa0cd96-eef1-5676-8a61-b3b8758bbffb"
Reexport = "189a3867-3050-52da-a836-e630ba90ab69"
Rotations = "6038ab10-8711-5258-84ad-4b1120ba62dc"
SHA = "ea8e919c-243c-51af-8825-aaa63cd721ce"
SciMLBase = "0bca4576-84f4-4d90-8ffe-ffa030f20462"
Serialization = "9e88b42a-f829-5b0c-bbe9-9e923198166b"
StaticArrays = "90137ffa-7385-5640-81b9-e52037218182"
Statistics = "10745b16-79ce-11e8-11f9-7d13ad32a3b2"
StatsBase = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"
Sundials = "c3572dad-4567-51f8-b174-8c6c989267f4"
SymbolicIndexingInterface = "2efcf032-c050-4f8e-a9bb-153293bab1f5"
SymbolicUtils = "d1185830-fcd6-423d-90d6-eec64667417b"
Timers = "21f18d07-b854-4dab-86f0-c15a3821819a"
VortexStepMethod = "ed3cd733-9f0f-46a9-93e0-89b8d4998dd9"
WinchModels = "7dcfa46b-7979-4771-bbf4-0aee0da42e1f"

[weakdeps]
ControlPlots = "23c2ee80-7a9e-4350-b264-8e670f12517c"

[extensions]
KiteModelsControlPlotsExt = "ControlPlots"

[compat]
ADTypes = "1.14.0"
Aqua = "0.8.11"
AtmosphericModels = "0.3"
BenchmarkTools = "1.6"
CodecXz = "0.7.4"
Colors = "0"
ControlPlots = "0.2.4"
ControlSystemsBase = "1"
DSP = "0.7.10"
Dierckx = "0.5.4"
DiffEqBase = "6.161.0"
DiscretePIDs = "0.1.5"
DocStringExtensions = "0.9.4"
Documenter = "1.10.1"
Interpolations = "0.15.1"
JLD2 = "0.5"
KitePodModels = "0.3.8"
KiteUtils = "0.10.15"
LaTeXStrings = "1.4.0"
LinearAlgebra = "1.10, 1.11"
LinearSolve = "~2.39.0, 3"
ModelingToolkit = "~9.78.0"
NLSolversBase = "~7.8.3"
NLsolve = "4.5"
NonlinearSolve = "4.8.0"
OrdinaryDiffEqBDF = "1.5.0"
OrdinaryDiffEqCore = "1.23.0"
OrdinaryDiffEqNonlinearSolve = "1.6.1"
PackageCompiler = "2.0"
Parameters = "0.12"
Pkg = "1.10, 1.11"
PrecompileTools = "1.2, 1.3"
REPL = "1.10.0, 1.11.0"
Reexport = "1.1, 1.2"
Rotations = "1.7"
SHA = "0.7.0"
SciMLBase = "<2.115"
Serialization = "1.10, 1.11"
StaticArrays = "1.9.7"
Statistics = "1"
StatsBase = "0.34"
Sundials = "4.24"
SymbolicIndexingInterface = "0.3"
SymbolicUtils = "3.25"
Test = "1"
Timers = "0.1.5"
VortexStepMethod = "1.2.6"
WinchModels = "0.3.6"
julia = "1.10, 1.11"

[extras]
Aqua = "4c88cf16-eb10-579e-8560-4a9242c79595"
BenchmarkTools = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf"
Colors = "5ae59095-9a9b-59fe-a467-6f913c188581"
ControlPlots = "23c2ee80-7a9e-4350-b264-8e670f12517c"
ControlSystemsBase = "aaaaaaaa-a6ca-5380-bf3e-84a91bcd477e"
DSP = "717857b8-e6f2-59f4-9121-6e50c889abd2"
Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
JLD2 = "033835bb-8acc-5ee8-8aae-3f567f8a3819"
LaTeXStrings = "b964fa9f-0449-5b57-a5c2-d3ea65f4040f"
PackageCompiler = "9b87118b-4619-50d2-8e1e-99f35a4d4d9d"
StatsBase = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["Test", "BenchmarkTools", "PackageCompiler", "Documenter", "ControlPlots", "Colors", "LaTeXStrings", "StatsBase", "JLD2", "Aqua", "DSP", "ControlSystemsBase"]

NonlinearSolversBase is indeed limited in the version.

See if you update now if you get the NonlinearSolveBase v1.16.1 patch.

All green again: GitHub - OpenSourceAWE/AWEMeta.jl: Integration tests for OpenSourceAWE packages

Not so sure if because of my fix or because of your fix, though.