search

SciML / DiffEqBase.jl

The lightweight Base library for shared types and functionality for defining differential equation and scientific machine learning (SciML) problems
Other
310 stars 111 forks source link

create API for tstop aliasing system #1077

Open isaacsas opened 2 weeks ago

isaacsas commented 2 weeks ago

Per discussions @ChrisRackauckas and I had around https://github.com/SciML/JumpProcesses.jl/issues/442 it would be nice to be able to have users tell us we can alias their tstops vector in JumpProcesses so we don't need to allocate a new vector for each call to solve.

ChrisRackauckas commented 2 weeks ago

My plan is to create a keyword argument alias which then has a struct ODEAliases <: AbstractAliasSpecifier etc., that holds booleans/nothing for each thing that can be aliased. nothing for default behavior, true/false for forced aliasing, de-aliasing. This can then be rolled out for every problem type uniformly, and include booleans to cover the keyword arguments.

ChrisRackauckas commented 2 weeks ago

@jClugstor does this specification make sense?

ChrisRackauckas commented 2 weeks ago

You'll find:

alias_u0: allows the solver to alias the initial condition array that is contained in the problem struct. Defaults to false.

in DiffEq

alias_A::Bool: Whether to alias the matrix A or use a copy by default. When true, algorithms like LU-factorization can be faster by reusing the memory via lu!, but care must be taken as the original input will be modified. Default is true if the algorithm is known not to modify A, otherwise is false. alias_b::Bool: Whether to alias the matrix b or use a copy by default. When true, algorithms can write and change b upon usage. Care must be taken as the original input will be modified. Default is true if the algorithm is known not to modify b, otherwise false.

in LinearSolve. Etc. All of that should get folded into just these more general structs, and the old way should get deprecated to just setting values of the struct.

jClugstor commented 2 weeks ago

I think I get it. alias should be a keyword of ODEProblem, LinearProblem, etc. that would be of type e.g. ODEAliases and LinearAliases respectively. And each concrete subtype of AbstractAliasSpecifier should hold boolean values that correspond to the parts of their corresponding problems that can be aliased.

ChrisRackauckas commented 2 weeks ago

Yes exactly.

jClugstor commented 1 week ago

Should the types ODEAliases and LinearAliases etc. be defined in SciMLBase?

ChrisRackauckas commented 1 week ago

yes

jClugstor commented 5 days ago

I'm thinking that the problem types will need a new field to hold the AbstractAliasSpecifiers, does that sound right?

ChrisRackauckas commented 4 days ago

I don't think so, they will just be a new common kwarg to solve.