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

Add BVPFunction #370

Merged
merged 10 commits into from
Sep 4, 2023
Merged

Add BVPFunction #370

merged 10 commits into from
Sep 4, 2023

Conversation

ErikQQY
Copy link
Member

@ErikQQY ErikQQY commented Jan 19, 2023

This PR adds BVPFunction. I think it would be nice for BoundaryValueDiffEq.jl to have this feature, since we have all kinds of *Function for all kinds of problems.

It is very interesting that after I added the BVPFunction feature to SciMLBase.jl and used the simple pendulum example to test if the BVPFunction can be directly used to solve the problem, and tada!🎉

bvpfunction

simplependulum

Signed-off-by: ErikQQY <[email protected]>
@ChrisRackauckas
Copy link
Member

I'm going to hold onto this: I'm not quite convinced that BVPs need a different function since they are just ODEs with extra boundary conditions. We are going to do a BVP overhaul quite soon though, so we'll evaluate it as we start making new BVP functionality and see what extra fields we could potentially use.

@ErikQQY
Copy link
Member Author

ErikQQY commented Jan 19, 2023

Sure, I will follow the BVP overhaul and keep this PR as a record in case a BVPFunction is needed.

@codecov
Copy link

codecov bot commented Aug 11, 2023

Codecov Report

Merging #370 (30fb3c2) into master (cce1ce0) will increase coverage by 1.43%.
Report is 19 commits behind head on master.
The diff coverage is 61.76%.

@@            Coverage Diff             @@
##           master     #370      +/-   ##
==========================================
+ Coverage   53.73%   55.17%   +1.43%     
==========================================
  Files          47       50       +3     
  Lines        3584     3701     +117     
==========================================
+ Hits         1926     2042     +116     
- Misses       1658     1659       +1     
Files Changed Coverage Δ
src/SciMLBase.jl 71.42% <ø> (ø)
src/ensemble/basic_ensemble_solve.jl 80.18% <ø> (+5.66%) ⬆️
src/ensemble/ensemble_solutions.jl 44.95% <0.00%> (+15.32%) ⬆️
src/ensemble/ensemble_problems.jl 40.90% <10.00%> (+2.81%) ⬆️
src/scimlfunctions.jl 60.83% <70.58%> (+1.46%) ⬆️
src/problems/bvp_problems.jl 52.00% <100.00%> (-4.67%) ⬇️

... and 17 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@ErikQQY
Copy link
Member Author

ErikQQY commented Aug 11, 2023

I added bcjac and bcjac_prototype, but the test cases are not covering all of the new features. Need some review to continue on this.

@ChrisRackauckas @avik-pal

Signed-off-by: ErikQQY <[email protected]>
Signed-off-by: ErikQQY <[email protected]>
BVProblem{isinplace(f, 4)}(f, bc, u0, tspan, args...; kwargs...)
end

function BVProblem(f, bc, u0, tspan, p = NullParameters(); kwargs...)
BVProblem(ODEFunction(f), bc, u0, tspan, p; kwargs...)
BVProblem(BVPFunction(f, bc), bc, u0, tspan, p; kwargs...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If BVPFunction stores bc should be duplicate the storage in BVProblem again?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, indeed, the problem construction process in BVProblem is similar with SDEProblem, they both have duplicate bc in BVProblem and g in SDEProblem, but if we want to have a BVPFunction stores both f and bc, duplicating bc could really making the problem constructor concise. We need to note that when we are unpacking BVProblem, we actually get a BVPFunction but not f.

function SDEProblem(f, g, u0, tspan, p = NullParameters(); kwargs...)
SDEProblem(SDEFunction(f, g), g, u0, tspan, p; kwargs...)
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case it's fair to stay consistent.

Maybe we can add an additional dispatch on BVPFunction where we automatically pull out the bc during problem construction that way user wont have to do BVProblem(BVPFunction(f, bc), bc...) and instead can specify BVProblem(BVPFunction(f, bc)....)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean a dispatch on BVProblem right? Just updated and now we can directly specify BVProblem(BVPFunction(f, bc).....) to construct a BVProblem.
Do we need to do the same for SDEProblem and SDEFunction? The problem construct of SDEProblem also need users to do somthing like SDEProblem(SDEFunction(f, g), g), see here: https://docs.sciml.ai/DiffEqDocs/stable/tutorials/sde_example/#Using-Higher-Order-Methods

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChrisRackauckas do you think this is a valid API choice? Is there a particular reason other Problem Types don't have this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you handle downstream?

Copy link
Member Author

@ErikQQY ErikQQY Aug 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I am working on fixing downstream errors

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a little lost here, there are three ways of constructing a BVProblem:
(1). Directly construction from scratch

prob = BVProblem(f, bc, u0, tspan)

(2). Use BVPFunction

prob = BVProblem(BVPFunction(f, bc), u0, tspan)

(3). Another way of using BVPFunction

prob = BVProblem(BVPFunction(f, bc), bc, u0, tspan)

As for SDEProblem, the definitions are similar, so my question is that it looks the (2) and (3) dispatches can't exist at the same time, so I think we are deprecating (3) and using (2) instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like deprecating (3) and using (2) in SDEProblem and SDEFunction is way more complicated than BVProblem and BVPFunction. SplitSDEProblem, DynamicalSDEProblem and maybe some functions in ModelingToolkit.jl and JumpProcess.jl etc. are all relying on (3) in problem constructor, the new change in this PR would cause a lot of errors and break a lot of APIs.

end

function SDEProblem(f, g, u0, tspan, p = NullParameters(); kwargs...)
SDEProblem(SDEFunction(f, g), g, u0, tspan, p; kwargs...)
end

function SDEProblem(f::AbstractSDEFunction, u0, tspan, p = NullParameters(); kwargs...)
SDEProblem(f, f.g, u0, tspan, p; kwargs...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this fallback won't work since it will drop information like Jacobian types.

Signed-off-by: ErikQQY <[email protected]>
@ErikQQY
Copy link
Member Author

ErikQQY commented Aug 25, 2023

Now BVP and SDE problems can be constructed using either:

BVProblem(f, bc, u0, tspan)
BProblem(f, g, u0, tspan)

or

BVProblem(fun, u0, tspan)
SDEProblem(fun, u0, tspan)

new_bvp
new_sde

@ErikQQY
Copy link
Member Author

ErikQQY commented Sep 4, 2023

I am still a little concerned the breaking changes would affect a lot, as can be seen from the CI status, the API changes especially SDEFunction and SDEProblem would make a lot of packages fail, so I need a confirmation before moving forward(update the downstream usage of SDEFunction and SDEProblem ). @ChrisRackauckas @avik-pal

@avik-pal
Copy link
Member

avik-pal commented Sep 4, 2023

If the SDE thing requires a lot of patching, can we decouple it from the BVPFunction work? The BVP function is non-breaking IIUC.

@ErikQQY
Copy link
Member Author

ErikQQY commented Sep 4, 2023

If the SDE thing requires a lot of patching, can we decouple it from the BVPFunction work? The BVP function is non-breaking IIUC.

Yeah agreed, I think we can first go with the BVP stuff, then update the SDE things in another PR.

Signed-off-by: ErikQQY <[email protected]>
@ChrisRackauckas ChrisRackauckas merged commit 4c0fcdf into SciML:master Sep 4, 2023
52 of 61 checks passed
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

Successfully merging this pull request may close these issues.

3 participants