math: solve_pde function for PDE problems

Summary:

Use solve_pde to solve PDEs.

Description:

The design involves cmdstan, stan, and math. See also https://github.com/stan-dev/stan/issues/2567. This issue is about Math repo only.

In order to solve PDE, similar to ODE solver in Stan, the PDE is provided through a functor. Unlike ODE solver, we cannot ship a PDE library with Stan Math. Alternatively, the user is asked to provide his own PDE solver. His workflow could be the following.

  • provide a functor that uses external PDE solver. The functor has the following signature
  inline std::vector<std::vector<double> >
  operator()(const std::vector<double>& theta,
             const bool need_sens,
             const std::vector<double>& x_r,
             const std::vector<int>& x_i,
             std::ostream* msgs = nullptr);

The functor returns PDE solution(quantity of interest) when need_sens=0, and returns PDE solution together with its gradient with respect to theta(parameters) when need_sens=1.

  • call solve_pde, with the above functor as the first argument. Within the solve_pde function, the above functor calculates PDE solution and sensitivity, andvar variables are constructed based on these values.
  • provide Makefile for the external PDE solver. See separate issue #934 .

The user/PDE developer does not need to know utilize stan::math::var to write the above functor. He just needs to decide the behavior of the PDE solver: how the solution and the sensitivity are calculated. solve_pde should be able to take these values and construct proper var items, possibly using precomputed_gradient.

Additional Information:

Provide any additional information here.

Current Version:

v2.17.0

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 36 (36 by maintainers)

Most upvoted comments

As I mentioned in https://github.com/stan-dev/stan/issues/2567, this is indeed true to any external library. for 3 I don’t think asking PDE developer to maintain a fork is a better option(I’m doing that with Torsten, and I’m desperately looking for alternatives) then providing a good API.

There’s nothing here that’s PDE specific, so is the goal to interface with external software in general?

It seems like there are three big components of all these pull reqs:

  1. The high level interface (that would appear in .stan files)
  2. The mechanism for working with the autodiff library without having to worry too much about the details of vars
  3. Whatever is needed to link in external libraries

3 seems like a support nightmare to me, and 1 seems easy to get around (if someone can build petsc, I’ll hazard they can figure out how to get the Rstan/cmdstan external C++ stuff working, even if those are hacky solutions). Seems to me like if someone has some big fancy weird external solver they need to incorporate in Stan they could maintain it as a fork? That’s what I do for my regular job – not that my development patterns are anything to emulate…

I’m working with Bob now on 2, for other reasons, but it’s the same goal: https://github.com/stan-dev/math/pull/924 . I’ll be full time on this until September. We think it’s a good idea too – and someone else coming up with it independently seems like a good sign 😛. Fingers crossed that should progress quickly.

Maybe this should be an item for the engineering part of the Thursday meeting?