Conversation
- also has a working test: events.jl
| sol = solve(prob, daskr(),save_timeseries=false) | ||
| sol = solve(prob, daskr(), saveat = saveat, isdiff = [true, true, false]) | ||
| sol = solve(prob, daskr(), saveat = saveat, | ||
| sol = solve(prob, DASKR.Algorithm()) |
There was a problem hiding this comment.
Is there a good reason to change the name? I would be surprised if another package wants to use the function daskr().
There was a problem hiding this comment.
For proper capitalization. daskr is/was a type constructor. I don't like Daskr. DASKRAlg or DASKRAlgorithm don't look as readable to me as DASKR.Algorithm, particularly since types are shown with the module often (DASKR.DASKRAlg).
There was a problem hiding this comment.
Alright. It's a little odd for it to be the only algorithm not represented directly by the algorithm name, but it's fine.
|
Sundials was stalled because GC finalizers don't work well without custom allocators since Julia cannot know the size of the memory that is pointed too. Would this be a problem here as well? |
|
I was wondering about that, too. I'm guessing it won't be a problem here because all allocation is done by Julia. |
initandstepfunctionality so far.solvehasn't been updated.stepdoesn't update the solution.