Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Galerkin Approximation

ethanepperly.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Galerkin Approximation

#11

Post by bunje »

mpoteat wrote: post #6

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.

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.

Re: Galerkin Approximation

#12

Post by magicalhippo »

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.

[1]: https://fenicsproject.org/

Re: Galerkin Approximation

#13

Post by adgjlsfhk1 »

magicalhippo wrote: post #12

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 h…

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.

Re: Galerkin Approximation

#14

Post by knlje »

adgjlsfhk1 wrote: post #13
magicalhippo wrote: post #12

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 h…

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 languag…

These packages you mention are not suitable for the typical use cases of the finite element method. There are some packages in the Julia ecosystem that may be suitable. I have no recent experience on using them though.

Re: Galerkin Approximation

#15

Post by pvitz »

pmiller2 wrote: post #9
activatedgeek wrote: post #4

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 i…

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. https://en.wikipedia.org/wiki/Quasi-Monte_Carlo_method

Just a guess, but if you think about Sobol sequences, maybe the available dimensions get exhausted in this use case and then QMC doesn't perform well anymore.

Re: Galerkin Approximation

#16

Post by orbifold »

adgjlsfhk1 wrote: post #13
magicalhippo wrote: post #12

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 h…

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 languag…

The constant shilling for Julia gets old after a while. When it comes to numerical mathematics the implementation language is just a way to express ideas that are more or less independent of whatever language you are using. Last time I checked Julia had close to no professional grade libraries for PDE solving , while there are multiple deal.ii, FenICs, petsc high quality libraries for C++. Don’t get me wrong Julia is great, but what really matters is the quality of the available libraries. The differential equations work in Julia is nice and obviously the resulting code is performant, but a ton of work in numerical mathematic is spent on adapting methods to specific problems and at that point C++ feels like a much nicer choice to me in many cases.

Re: Galerkin Approximation

#17

Post by krull10 »

orbifold wrote: post #16
adgjlsfhk1 wrote: post #13

Earlier quoted context omitted.

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 languag…

The constant shilling for Julia gets old after a while. When it comes to numerical mathematics the implementation language is just a way to express ideas that are more or less independent of whatever language you are using. Last time I checked Julia had close to no professional grade libraries for PDE solving , while there are multiple deal.ii, FenICs, petsc high quality libraries for C++. Don’t get me wrong Julia is…

Julia has some young projects that look promising as future broad FEM/PDE discretization libraries, like Gripap.jl, but they are certainly not at the level of the more mature C++-based libraries you mention.

For my own work I would never say C++ is a nicer choice; I hate writing and dealing with C++ code. It is however a necessary choice since that is where many of best the libraries live.

Re: Galerkin Approximation

#18

Post by nextaccountic »

magicalhippo wrote: post #12

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 h…

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

Re: Galerkin Approximation

#19

Post by neutronicus »

mpoteat wrote: post #6

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.

If your solution is troublesome in some way (discontinuous, singular), then you can't rely on methods that need it to have derivatives

Re: Galerkin Approximation

#20

Post by curt15 »

mpoteat wrote: post #6

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.

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.

Post reply on HN