# Call for vote on Adjoint ODE Design Doc PR

**URL:** <https://discourse.mc-stan.org/t/call-for-vote-on-adjoint-ode-design-doc-pr/21829>\
**Category:** Developers\
**Created:** [April 12, 2021, 7:56am UTC](https://discourse.mc-stan.org/t/call-for-vote-on-adjoint-ode-design-doc-pr/21829 "2021-04-12T07:56:22Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![bbbales2](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bbbales2/32/77_2.png) [@bbbales2](https://discourse.mc-stan.org/u/bbbales2)\
**Post date:** [April 12, 2021, 4:02pm UTC](https://discourse.mc-stan.org/t/call-for-vote-on-adjoint-ode-design-doc-pr/21829/2 "2021-04-12T16:02:06Z")

</div>

I dunno how we’re doing the votes, but I’m in favor of this.

1. There is a use case (this scales better with parameters)
2. It seems like at least a couple people other than @wds15 were able to run this (see [here](https://discourse.mc-stan.org/t/adjoint-ode-prototype-rfc-please-test/21212))
3. There’s no new software dependencies, so if we ever want to deprecate this interface, we just plug in another ODE solver behind the scenes for compatibility
4. There’s a bunch of work to systemetize the ODE tests [here](https://github.com/stan-dev/math/pull/2432), so if this thing can fit into that testing framework then I am less worried about maintenance (it’ll be going through the same basic tests as all the other solvers + whatever specialized one it needs)

---

_[View the full topic](https://discourse.mc-stan.org/t/call-for-vote-on-adjoint-ode-design-doc-pr/21829)._
