-
-
Notifications
You must be signed in to change notification settings - Fork 105
SecondOrderDDEProblem (and underlying DynamicalDDEProblem) #14
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #14 +/- ##
=========================================
- Coverage 2.92% 2.87% -0.06%
=========================================
Files 37 37
Lines 2663 2712 +49
=========================================
Hits 78 78
- Misses 2585 2634 +49
Continue to review full report at Codecov.
|
function DynamicalDDEProblem(f::DynamicalDDEFunction,h::Function,tspan,p=NullParameters();kwargs...) | ||
DynamicalDDEProblem(f,h(p,first(tspan))...,h,tspan,p;kwargs...) | ||
end | ||
function DynamicalDDEProblem(f1::Function,f2::Function,args...;kwargs...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Varargs are used here so the optional v0
, u0
initial conditions can be handled by dispatch by the two constructors above, and the code doesn't have to be repeated for any of the following constructors. f1
and f2
's types are specified to be Function
so that the constructor doesn't just pull out the first 2 arguments of and try to pass on the rest, which would result in more confusing dispatch errors down the line if an incorrect call is made.
end | ||
function Base.getproperty(f::DynamicalDDEFunction, name::Symbol) | ||
if name === :f | ||
# Use the f property as an alias for calling the function itself, so DynamicalDDEFunction fits the same interface as DDEFunction as expected by the ODEFunctionWrapper in DelayDiffEq.jl. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See SciML/DelayDiffEq.jl#203: this is so that ODEFunctionWrapper
can expect all AbstractDDEFunction
s to define f.f
with the entire DDE.
Co-authored-by: David Widmann <devmotion@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good thanks.
Hey @ChrisRackauckas,
Following up on last semester, this PR has the plumbing necessary for
SecondOrderDDEProblem
that seems to be working well in Photron the last few weeks. It mirrors the structure ofSecondOrderODEProblem
, with the necessary changes in order to support a history function as well as 2 initial conditions. DelayDiffEq.jl requires a one-line change for this to work, because before it would only wrap the concreteDDEFunction
rather than anyAbstractDDEFunction
: SciML/DelayDiffEq.jl#203Once Photron reaches stability, I can add its Lienard-Wiechert solver to DiffEqProblemLibrary.jl/src/dde as an example of how to use this problem to solve relativistic physics.
Companion PRs: