Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inactive declaration ignored #2016

Open
ChrisRackauckas opened this issue Oct 28, 2024 · 4 comments
Open

Inactive declaration ignored #2016

ChrisRackauckas opened this issue Oct 28, 2024 · 4 comments

Comments

@ChrisRackauckas
Copy link
Contributor

MWE:

using OrdinaryDiffEq, Enzyme, StaticArrays

function lorenz!(du, u, p, t)
    du[1] = 10.0(u[2] - u[1])
    du[2] = u[1] * (28.0 - u[3]) - u[2]
    du[3] = u[1] * u[2] - (8 / 3) * u[3]
end

const _saveat =  SA[0.0,0.25,0.5,0.75,1.0,1.25,1.5,1.75,2.0,2.25,2.5,2.75,3.0]

function f(y::Array{Float64}, u0::Array{Float64})
    tspan = (0.0, 3.0)
    prob = ODEProblem{true, SciMLBase.FullSpecialize}(lorenz!, u0, tspan)
    sol = DiffEqBase.solve(prob, Tsit5(), saveat = _saveat, sensealg = DiffEqBase.SensitivityADPassThrough())
    y .= sol[1,:]
    return nothing
end;
u0 = [1.0; 0.0; 0.0]
d_u0 = zeros(3)
y  = zeros(13)
dy = zeros(13)

Enzyme.autodiff(Reverse, f,  Duplicated(y, dy), Duplicated(u0, d_u0));

gives:

cannot handle unknown binary operator:   %97 = add i64 %96, 1, !dbg !371


Stacktrace:
 [1] +
   @ ./int.jl:87
 [2] increment_accept!
   @ ~/.julia/packages/OrdinaryDiffEqCore/qpjip/src/integrators/integrator_utils.jl:274
 [3] _loopfooter!
   @ ~/.julia/packages/OrdinaryDiffEqCore/qpjip/src/integrators/integrator_utils.jl:234


Stacktrace:
  [1] _postamble!
    @ ~/.julia/packages/OrdinaryDiffEqCore/qpjip/src/integrators/integrator_utils.jl:154
  [2] loopfooter!
    @ ~/.julia/packages/OrdinaryDiffEqCore/qpjip/src/integrators/integrator_utils.jl:207 [inlined]
  [3] solve!
    @ ~/.julia/packages/OrdinaryDiffEqCore/qpjip/src/solve.jl:555
  [4] #get_concrete_problem#69
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1187 [inlined]
  [5] get_concrete_problem
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1179 [inlined]
  [6] #solve_up#53
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1086
  [7] solve_up
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1078 [inlined]
  [8] #solve#51
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1015 [inlined]
  [9] solve
    @ ~/.julia/packages/DiffEqBase/frOsk/src/solve.jl:1005 [inlined]
 [10] f
    @ ./REPL[9]:4 [inlined]
 [11] diffejulia_f_6507wrap
    @ ./REPL[9]:0
 [12] macro expansion
    @ ~/.julia/packages/Enzyme/BRtTP/src/compiler.jl:8137 [inlined]
 [13] enzyme_call
    @ ~/.julia/packages/Enzyme/BRtTP/src/compiler.jl:7703 [inlined]
 [14] CombinedAdjointThunk
    @ ~/.julia/packages/Enzyme/BRtTP/src/compiler.jl:7476 [inlined]
 [15] autodiff
    @ ~/.julia/packages/Enzyme/BRtTP/src/Enzyme.jl:491 [inlined]
 [16] autodiff
    @ ~/.julia/packages/Enzyme/BRtTP/src/Enzyme.jl:537 [inlined]
 [17] autodiff(::ReverseMode{…}, ::typeof(f), ::Duplicated{…}, ::Duplicated{…})
    @ Enzyme ~/.julia/packages/Enzyme/BRtTP/src/Enzyme.jl:504
 [18] top-level scope
    @ REPL[14]:1
Some type information was truncated. Use `show(err)` to see complete types.

but that function is already marked as inactive

function EnzymeCore.EnzymeRules.inactive_noinl(
        ::typeof(OrdinaryDiffEqCore.increment_accept!), args...)
    true
end

Full stack trace: enzyme.txt

@ChrisRackauckas
Copy link
Contributor Author

Note that this should be the final stage of SciML/OrdinaryDiffEq.jl#2282

@wsmoses
Copy link
Member

wsmoses commented Oct 28, 2024

Are you able to reduce this to a MWE without the sciml stack as dependencies?

The fact that the type isn't deduced is odd and we should be able to fix it where the inactive isn't needed at all (but requires debugging on a simpler example)

@ChrisRackauckas
Copy link
Contributor Author

I don't know how to reduce this. It's the same thing as what was originally #1636 . In Enzyme v0.12 I just worked around it by moving the pieces that were weird out to a function an inactiviting them, though I could never isolate why it acted so weird there.

@wsmoses
Copy link
Member

wsmoses commented Oct 30, 2024

I mean worst case you can splat in the defn's of all functions/structs in the imported packages used in the above and try to delete some of the struct elements

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants