-
-
Notifications
You must be signed in to change notification settings - Fork 368
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
Interfacing with 3rd-party PDE libraries #2567
Comments
The rstan process for including external files is a bit different although slightly easier. We just need to make people who are using this mechanism aware of it. |
What's the motivation for the name `forward_pde`?
…On Mon, Jul 02, 2018 at 11:17 PM, ***@***.***>wrote:
The *rstan* process for including external files is a bit different
although slightly easier. We just need to make people who are using this
mechanism aware of it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2567 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZ_F2AWRtQIqbke7kCYv4y-UPLKxMy2ks5uCuJigaJpZM4VALuQ>
.
|
It solves a forward pde problem, compared to inverse problem. |
Got it. Doesn't the literature and other software just call that "solving a
pde"? I did a quick search and it looks like most other software functions
name the function "pde" or something similar without calling it "forward."
Are we planning on tackling inverse pdes soon?
…On Thu, Jul 05, 2018 at 9:36 AM, Yi ***@***.***>wrote:
What's the motivation for the name forward_pde?
It solves a forward pde problem
<https://onlinelibrary.wiley.com/doi/10.1002/9781118478141.ch3>, compared
to inverse problem.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2567 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZ_F3NLHmzh3Gk9qhCC3YPrzg2kRuYjks5uDhZZgaJpZM4VALuQ>
.
|
I want to emphasize we're "forwarding" the parameter to QoI. Essentially we ARE solving inverse problem (using data to trace back to system parameters), by solving forward problem repeatedly. But if by "inverse" you mean inference of parameter in an infinite function space like in tomography, then probably not. But it's more of a PDE solver issue than a Stan issue. |
What's QoI?
…On Thu, Jul 05, 2018 at 10:33 AM, Yi ***@***.***>wrote:
I want to emphasize we're "forwarding" the parameter to QoI.
Essentially we ARE solving inverse problem (using data to trace back to
system parameters), by solving forward problem repeatedly. But if by
"inverse" you mean inference of parameter in an infinite function space
like in tomography, then probably not.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2567 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZ_F-h-4uM7RU-rZomMSr-tTN3spu9sks5uDiPLgaJpZM4VALuQ>
.
|
Quantity of interest. Sorry, forgot that's PDE jargon. It's essentially the observable with its data collected. |
More help? What's "observable with its data collected"?
I don't envision the Stan language being a PDE-specific language, so
perhaps more descriptive names would be better? Things that would show up
naturally or when searching?
I'm now looking at the doc for some of these packages. It looks like you're
trying to abstract a lot of functionality away behind this single function.
Is that the intent?
Also, what do you mean by "the rationale is to relieve PDE lib user from
working on vars"? I don't understand that statement. What's a "PDE lib"? At
the math repo level, wouldn't they need to know about stan::math::var?
…On Thu, Jul 05, 2018 at 10:41 AM, Yi ***@***.***>wrote:
Quantity of interest. Sorry, forgot that's PDE jargon. It's essentially
the observable with its data collected.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2567 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAZ_F58Mx0z2TWFJGcTuDe0pyTUsf_fbks5uDiWugaJpZM4VALuQ>
.
|
I'm open to any other names.
Yes. Stan only cares about the PDE solution result and the sensitivity, so we can do autodiff regarding that result. PDE solver developers don't need to touch Things better explained in an example. Say in flow simulation around a car, we collect noisy data of drag force, the design parameter(theta) is the length of the vehicle. So we do |
Unlike ODE, I don't think we can find a typical usage in a single PDE solver, hence the external library interface and abstracting away the PDE solution process. As to name, will |
It's also Andrew's jargon and hence shows up in Stan doc all over the place.
… On Jul 5, 2018, at 10:41 AM, Yi Zhang ***@***.***> wrote:
Quantity of interest. Sorry, forgot that's PDE jargon. It's essentially the observable with its data collected.
|
This is exactly the same motivation as behind the adjoint-Jacobian formulation of reverse mode that Ben Bales is working on now. It lets the user write the value function and adjoint-Jacobian product function without every having to worry about var types.
In fact, if the result is multivariate, this can be more efficient in memory than storing multiple gradients in a Jacobian, so the adjoint-Jacobian product may be worth thinking about here, too.
|
Naming's hard and almost everyone's bad at it. Hence this popular quote from Phil Karlton:
… There are only two hard things in Computer Science: cache invalidation and naming things.
|
The current design treats PDE solver as black box. This is feasible for small-medium size problems, For large problems one usually needs some reduced-order/surrogate model for the PDE to make it tractable. Again, this is more of a PDE solver issue instead of Stan issue. One caveat is that along |
Currently Stan doesn't have a sparse matrix system, and the mpi system is still young. Without these two common denominators I don't think we can get deeper than a black-box PDE feature design. |
I agree that this is the ideal design — we do not want to go down the path of supporting PDE solvers, and this provides an elegant way to exposing Stan to custom solvers.
… On Jul 6, 2018, at 13:14, Yi Zhang ***@***.***> wrote:
Currently Stan doesn't have a sparse matrix system, and the mpi system is still young. Without these two common denominators I don't think we can get deeper than a black-box PDE feature design.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I think |
Summary:
Allow 3rd-party PDE(partial differential equation) libraries to be used to perform inference that involve PDEs.
Description:
The design involves
cmdstan
,stan
, andmath
. This issue ticket solicits the discussion regarding the related design in all the repos. See stan-dev/math#931 for corresponding issue for Math library.Design goals
user_header
and Stan's external C++ interface.This design allows the user to use his own PDE solver in Stan, by using
solve_pde
function andmake
withSTANCFLAGS=--allow_undefined
. Similar to ODE solver in Stan, the PDE is provided through a functor(Stan's user-defined function). The actual action of the functor is provided through the external PDE solver inuser_header.hpp
(see example below). In this design the user is asked to do the following to use his external PDE solver:laplace_model
.solve_pde
, with the above stan user-function as the first argument.Makefile
for the external PDE solverAn additional design goal is to allow stan to coordinate MPI computation with the external lib. This belongs to next stage, will be not be discussed in the rest of the discussion.
Also note that the design works on any 3rd-party library that can do sensitivity analysis, but my interest is mostly in PDE.
The rest subsections introduce the proposed design.
forward_pde
solve_pde
functionImplementation here
https://github.com/yizhang-cae/math/tree/forward_pde
forward_pde
solve_pde
inmath
maps input PDE model functor and parameters to QoI:This is similar to ODE solver, except that all model-related information is provide by functor
pde
, which as the following signatureThe rationale is to relieve PDE lib user from working on
vars
. He needs to make decision onneed_sens
?),theta
,and doesn't need to know how the result is incorporated into
math
.Linking
forward_pde
to Stan languageImplementation is at
https://github.com/yizhang-cae/stan/tree/forward_pde
Nothing new here, just exposing a high-order function.
Using
forward_pde
solve_pde
in Stan would be something like the following.make
incmdstan
In order to
make
the above model, incmdstan
two switches are added toMakefile
WITH_EXTERN_PDE
:=1
indicates user needs to supplyuser_header.hpp
.EXTERN_PDE_MAKEFILE
: withWITH_EXTERN_PDE=1
user needs to providemake
info regarding his library, so that the above Laplace model can be built withThe example and the
Makefile
change can be found athttps://github.com/yizhang-cae/cmdstan/tree/forward_pde
Reproducible Steps:
Final model in
./examples/forward_pde_lapace
https://github.com/yizhang-cae/cmdstan/tree/forward_pde
Unit tests in the above
math
branch.Current Output:
n/a
Expected Output:
Three external libraries has been tested and included in unit tests. To verify you need to install these libraries and provide
make
info indicated in theMakefile
of the unit test directories inmath
repo.Pressure contour of the Darcy's flow from the MFEM unit test
Parameter(normalized porosity
k
) from Stan, based on simulated data.Additional Information:
Provide any additional information here.
Current Version:
v2.17.1
The text was updated successfully, but these errors were encountered: