And, guess what? Since, the Galerkin approximation requires one to choose a basis that is appropriate to the problem at hand, we now have a deep learning solution too (since neural network learning is essentially equivalent to learning an adaptive basis).
It is called the Deep Galerkin Method [1]. In a nutshell, the method directly minimizes the L2 error over the PDE, boundary conditions and initial conditions. The integral is tricky though, and computed via a Monte Carlo approximation.
Why would you use the Monte Carlo method when the quasi-Monte Carlo method converges so much more quickly? I admit, I am a little biased, because I worked on some QMC stuff in grad school, but it works really, really well in practice.
Check out the rest of the guy's blog. I desperately wish there were more resources where complex mathematical concepts were first introduced without all of the proofs.
A tangent, but I was exposed to the Galerkin approximation when learning about the Finite Element Method, well over 10 years ago.
As part of the course I got introduced to the FEniCS project[1].
They had Python code looking very much like the math equations generating C++ code at runtime, compiling it into a Python module which got dynamically loaded and executed.
This way they got speeds which rivaled or surpassed handwritten C++, as the C++ code could be optimized around the specific problem, but with superior ergonomics of writing the equations almost directly.
It really blew my mind. I had heard about Java doing JIT but this was on another level for me. Not terribly fancy these days but at the time it really helped me expand my thinking about how to solve problems.
Another project that works like this is devito https://www.devitoproject.org/ - the python code generates C code, calls gcc to compile it, dynamically links the object code with dlopen(), then calls the compiled code. That way, the hot code loop doesn't run in Python
You really should check out Approxfun.jl and DifferentialEquations.jl. The julia ecosystem for this type of thing is incredibly well developed. You get autodiff, auto-sparsity detection, auto-vectorization and more for free. Also, these tools leverage the fact that Julia is fast and has a good macro system so the code you generate is just normal Julia code, which can be used with any of the other tools of the language. Also multiple dispatch means that you don't have to use anything complicated to write this. Just write your equations "normally" and this all just works.
I find the general idea of treating differential equations as infinitely dimensional linear systems quite powerful. I was first introduced to the concept while studying quantum mechanics, but applications are everywhere.
I first encountered it for deriving finite element methods for structural analysis, and later as a general method for PDEs. Sadly this treatment is about as inscrutable as my grad level PDE course.
This made as little sense to me as it did when I was talking the Finite Element Methods class during graduate school.
Still don't quite understand why you can't just use Runge Kutta methods to numerically solve these problems. I became quite good at manipulating the symbols to derive variational solutions while having absolutely no idea what any of it meant.
Runge-kutta works when you’re given an initial condition and the derivative is with respect to just one variable (so you’re given f(t) just at t=0). What do you do when you’re given a boundary condition and the derivative is with respect to many variables? This.
I think variational problems are more naturally understood through energy minimization. You start with the energy of the system and try to minimize it via derivatives. Then you arrive at a variational problem. The differential equation is then more of an afterthought.
Finite differences is the PDE analogue of Runge-Kutta, and it is certainly used (in CFD for example). However, finite element methods have several advantages:
* It can handle PDEs on domains with complicated geometries, while finite differences really prefer rectangular domains. This consideration doesn't apply to ODEs which are always solved on one-dimensional intervals.
* For any numerical approximation it is important to have convergence guarantees, and as the blog post mentions, the analysis is much more well understood for finite elements, particularly on irregular geometries. Strang and Fix's 1973 book is the classic reference here.
[+] [-] activatedgeek|5 years ago|reply
It is called the Deep Galerkin Method [1]. In a nutshell, the method directly minimizes the L2 error over the PDE, boundary conditions and initial conditions. The integral is tricky though, and computed via a Monte Carlo approximation.
[1]: https://arxiv.org/abs/1708.07469
[+] [-] pmiller2|5 years ago|reply
https://en.wikipedia.org/wiki/Quasi-Monte_Carlo_method
[+] [-] GlenTheMachine|5 years ago|reply
[+] [-] magicalhippo|5 years ago|reply
As part of the course I got introduced to the FEniCS project[1].
They had Python code looking very much like the math equations generating C++ code at runtime, compiling it into a Python module which got dynamically loaded and executed.
This way they got speeds which rivaled or surpassed handwritten C++, as the C++ code could be optimized around the specific problem, but with superior ergonomics of writing the equations almost directly.
It really blew my mind. I had heard about Java doing JIT but this was on another level for me. Not terribly fancy these days but at the time it really helped me expand my thinking about how to solve problems.
[1]: https://fenicsproject.org/
[+] [-] nextaccountic|5 years ago|reply
[+] [-] adgjlsfhk1|5 years ago|reply
[+] [-] mscharrer|5 years ago|reply
[+] [-] greesil|5 years ago|reply
[+] [-] mpoteat|5 years ago|reply
Still don't quite understand why you can't just use Runge Kutta methods to numerically solve these problems. I became quite good at manipulating the symbols to derive variational solutions while having absolutely no idea what any of it meant.
[+] [-] rahimiali|5 years ago|reply
[+] [-] bunje|5 years ago|reply
[+] [-] curt15|5 years ago|reply
* It can handle PDEs on domains with complicated geometries, while finite differences really prefer rectangular domains. This consideration doesn't apply to ODEs which are always solved on one-dimensional intervals.
* For any numerical approximation it is important to have convergence guarantees, and as the blog post mentions, the analysis is much more well understood for finite elements, particularly on irregular geometries. Strang and Fix's 1973 book is the classic reference here.
[+] [-] neutronicus|5 years ago|reply