explicit RK docstrings

[ArnoStrouwen]

No description provided.

[ChrisRackauckas]

That looks nice!

[ArnoStrouwen]

I'm not sure how to get FUNCTIONNAME to work inside a function that defines the docstring.
Currently, it is just doing string interpoloation isntead of working with the @doc marcro.

[ChrisRackauckas]

@shashi or @YingboMa how did you manipulate the docs stuff for Symbolics?

[shashi]

@ChrisRackauckas it was working in old MTK when we split the package.

[ArnoStrouwen]

Do you perhaps know the solution to the above problem @mortenpi?

[mortenpi]

You're literally interpolating the string() value of the FUNCTIONNAME object into the string here, hence why it doesn't work. DocStringExtensions takes advantage of the fact that string interpolation in macro calls / docstrings is special, which is how it works in @doc "$FUNCTIONNAME ..." foo situations.

I don't see any way to make this work with DocStringExtensions, but you could, of course, work around it by passing the function name as an extra parameter to explicit_rk_docstring. I would suggest opening an issue at DocStringExtensions though, since this is an interesting case.

[MichaelHatherly]

Looks kind of like what @template is for perhaps. If that's stretching what the template macro can actually handle currently it may be possible to improve it's features to handle this case better.

[ArnoStrouwen]

@ChrisRackauckas What does williamson_condition do in ORK256?
Could you write a sentence or 2 describiting it.

[ChrisRackauckas]

williamson_condition allows for an optimization that allows fusing broadcast expressions with the function call f. However, it only works for Array types.

[ai-maintainer]

Thank you for your contribution! 

This pull request is too large for automated review.

Reviewed with AI Maintainer

[ArnoStrouwen]

@ChrisRackauckas Still need input on this and then RK explicit is done atleast.

• RKM needs a sentence describing the method
  Similar to RK4's:
  Explicit Runge-Kutta Method. The canonical Runge-Kutta Order 4 method. Uses a defect control for adaptive stepping using maximum error over the whole interval.
• Feagin methods are stubs
• Euler is a stub
• KuttaPRK2p5 is a stub

[ChrisRackauckas]

Test failure looks real

[ChrisRackauckas]

The v1.9 test failures look real.

[ArnoStrouwen]

The v1.9 test failures look real.

#2008 seems to also have these issues, so probably not related to this PR?

[ChrisRackauckas]

No, https://buildkite.com/julialang/ordinarydiffeq-dot-jl/builds/2716#0189d070-610b-4e37-8e35-24307a04760b/841-1134 doesn't show up in the other one.

[ChrisRackauckas]

That looks fishy https://github.com/SciML/OrdinaryDiffEq.jl/actions/runs/5795470854/job/15707118352?pr=1866#step:6:596 . Area all of the test errors known? I know the other ones seem to be from ITP (SciML/DiffEqBase.jl#917 @DaniGlez it would be good to figure out what happened post merge)

[DaniGlez]

Yeah, looking at the test failure in the Integrators_I suite there's a clear issue with the InternalITP solver, is that the only one?

[ChrisRackauckas]

Integrators_II, yes that's the only one.

[DaniGlez]

I took a look, it seems that I simply forgot to port the latest bugfixes from the SimpleNonlinearSolve version to the internal DiffEqBase one. I'll PR a fix soon.

[DaniGlez]

This should fix it, I believe: SciML/DiffEqBase.jl#919