sciml / daskr.jl

Interface to DASKR, a differential algebraic system solver for the SciML scientific machine learning ecosystem

DASKR

A solver for differential algebraic equations (DAE). This wraps the original DASKR FORTRAN solver. DASKR is a derivative of the DASSL solver with root finding.

An interface to the JuliaDiffEq common interface is also provided.

Common Interface Example

using DASKR
u0 = [1.0, 0, 0]
du0 = [-0.04, 0.04, 0.0]
tspan = (0.0,100000.0)

function resrob(r,yp,y,p,tres)
    r[1]  = -0.04*y[1] + 1.0e4*y[2]*y[3]
    r[2]  = -r[1] - 3.0e7*y[2]*y[2] - yp[2]
    r[1] -=  yp[1]
    r[3]  =  y[1] + y[2] + y[3] - 1.0
end

prob = DAEProblem(resrob,u0,du0,tspan)    
sol = solve(prob, daskr())

The options for solve are documented at the common solver options page. For more details, see the ODE Tutorial and the DAE Tutorial pages from DifferentialEquations.jl.

Citing

Please cite DifferentialEquations.jl and the original algorithm:

@article{rackauckas2017differentialequations,
  title={Differentialequations. jl--a performant and feature-rich ecosystem for solving differential equations in julia},
  author={Rackauckas, Christopher and Nie, Qing},
  journal={Journal of Open Research Software},
  volume={5},
  number={1},
  year={2017},
  publisher={Ubiquity Press}
}

@article{brown1994using,
  title={Using Krylov methods in the solution of large-scale differential-algebraic systems},
  author={Brown, Peter N and Hindmarsh, Alan C and Petzold, Linda R},
  journal={SIAM Journal on Scientific Computing},
  volume={15},
  number={6},
  pages={1467--1488},
  year={1994},
  publisher={SIAM}
}

@article{brown1998consistent,
  title={Consistent initial condition calculation for differential-algebraic systems},
  author={Brown, Peter N and Hindmarsh, Alan C and Petzold, Linda R},
  journal={SIAM Journal on Scientific Computing},
  volume={19},
  number={5},
  pages={1495--1512},
  year={1998},
  publisher={SIAM}
}

daskr.jl's Issues

Register and tag?

Of course, there's always more to do, but I think this library is ready for its first tag. What do you think?

Passing Jacobians

Similar to SciML/Sundials.jl#137, I am trying to find out Jacobian passing here. We can assume that it's passed along via f(Val{:jac},t,y,dy,gamma,out). Using your helper function @tshort, it should be as simple as:

if has_jac(f)
  (t, y, yp, pd, cj) -> f(Val{:jac},t,y,dy,cj,pd)
else
  jac = Int32[0]
end

What is `isdiff`?

Can you explain what isdiff does?

Migrate to JuliaDiffEq

Would you be willing to migrate this over to JuliaDiffEq? I'd like to fix up the common interface a bit.

Expose info17 options

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Common interface should expose linear solver support in its algorithm type

See Sundials algorithm for details on what it could look like.

Add non-negativity enforcement to the common interface DASKR

DASKR JuliaDiffEq common interface

Conversation starts here: tshort/FunctionalModels.jl#69

It has a crude/partial common API interface, but I didn't know what I was doing. I mainly copied the Sundials function.

I'll submit some PRs.

The common API doesn't support events. I think callbacks may still be a work in progress.

Yes. That is a big issue right now that we don't quite know how to solve. Maybe separating callback and event interfaces would do better than the current proposal of trying to have a common callback interface? The problem is that different packages need/can have very different code injected in via callbacks, so that's hard to standardize.

SciML/Roadmap#10

Also, it'll be challenging for the common API to handle things like a banded jacobian (not that we handle that now, but maybe someday).

Is passing this information as part of the algorithm type not possible (like how Sundials does it)? I see you have a flag for :dense which isn't used, so I guess the problem is more subtle (probably to do with the interop?).

Expose preconditioning in common interface

Register

@JuliaRegistrator register()

Problem with types when dealing with DAEs which explicitly conatin the time

I have just figured out that a problem will occur if your DAE System contains the time explicitly.
For illustration purposes a slightly modified the code example from the package description so that you can reproduce the error. The Problem seems to be that the time is not of type Float64 but rather of type Array{Float64,1}, which contains one single element. This means that t is something like
t = [1234.56] instead of t = 1234.56.

Here is the example code:

using DASKR
u0 = [1.0, 0, 0]
du0 = [-0.04, 0.04, 0.0]
tspan = (0.0,100000.0)

function resrob(tres, y, yp, r)
    #tres = tres[1]         # using this line in your code is a quick fix

    r[1]  = -0.04*y[1] + 1.0e4*y[2]*y[3]
    r[2]  = -r[1] - 3.0e7*y[2]*y[2] - yp[2]
    r[1] -=  yp[1]
    # the modification of the following line yields the error:
    # Cannot `convert` an object of type Array{Float64,1}
    # to an object of type Float64
    r[3]  =  y[1] + y[2] + y[3] - (1.0 + tres/100000.0)
end

prob = DAEProblem(resrob,u0,du0,tspan)
sol = solve(prob, daskr())