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

Select which Boost ODE methods to initially support #3

Open
nicklafarge opened this issue Nov 9, 2022 · 6 comments
Open

Select which Boost ODE methods to initially support #3

nicklafarge opened this issue Nov 9, 2022 · 6 comments
Labels
good first issue Good for newcomers

Comments

@nicklafarge
Copy link
Member

No description provided.

@nicklafarge nicklafarge added the good first issue Good for newcomers label Nov 9, 2022
@nicklafarge nicklafarge added this to the Requirements and Analysis milestone Nov 9, 2022
@rjpower4
Copy link
Member

rjpower4 commented Nov 9, 2022

@rjpower4
Copy link
Member

rjpower4 commented Nov 9, 2022

Do we plan on requiring Boost or do we want to allow use of other packages such as SUNDIALS... 😅

@nicklafarge
Copy link
Member Author

nicklafarge commented Nov 9, 2022

I'm definitely interested in exploring other options. The "choice" of boost so far is an inherited one from prior work, not for any specific reason. I guess we need to learn enough about what options are out there to make an informed choice as to which one is "best" for our project - or if there is a use case for supporting more than one. Some considerations that go along with any potential choices are understanding licensing, minimum supported c++ versions, and perhaps (eventually) benchmarks to see if there is a speed increase.

Exploring other underlying integration implementations is could also be a 2.0 task. Maybe we should prioritize getting the project up and running with boost, and then later revisit that choice and evaluate how we might improve it

@rjpower4
Copy link
Member

rjpower4 commented Nov 9, 2022

I think that sticking to boost at this point is a good call, but I think that we should try to design an abstraction around the integrator.

@nicklafarge
Copy link
Member Author

That sounds good. The current prototype has some repeated code anyway in that regard for converging events, so a degree of abstraction there would be helpful regardless of what other options we pursue

@nicklafarge
Copy link
Member Author

@rjpower4 I'm guessing you know a ton more about these options off the cuff than I do, so I'm wondering what insight you may have about them. I currently use Runge-Kutta-Fehlberg 78 exclusively. What sorts of motivations are there for the others? I think maybe, for now, we should have specific reasons for whichever ones we choose to initially support.

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

No branches or pull requests

2 participants