[HN Gopher] Eighty Years of the Finite Element Method
___________________________________________________________________
Eighty Years of the Finite Element Method
Author : leephillips
Score : 129 points
Date : 2022-11-05 12:31 UTC (10 hours ago)
(HTM) web link (link.springer.com)
(TXT) w3m dump (link.springer.com)
| icks wrote:
| My first programming role was on the back of work by an engineer
| in this article. The core of the solver was a FORTRAN
| implementation of a paper on p-convergence. It was really amazing
| seeing our software predict how a small crack in a part of an
| aircraft would propagate. The 3D model produced matched the
| photograph shared later.
|
| The lead developer (at the time) once said that the biggest
| software failure we can have is not incorrect results, but
| incorrect results without the user knowing. This is probably why
| I am so bothered by silent failures in my big company role now.
| wheelinsupial wrote:
| I know it's not a simple answer, but how would you embed checks
| to flag or highlight potentially incorrect results to the user?
| kqr wrote:
| For physical processes, you can sometimes lean on
| conservation laws. Financial, no-arbitrage "laws". Sometimes
| it can help to run two different models, or different
| numerical methods, and compare their results. More generally,
| it's very, very hard. I am fairly sure there are multiple
| published results in computational fluid dynamics that are
| subtly wrong.
| meheleventyone wrote:
| A lot of computer models are deliberately wrong but useful
| as well which is another ball game in terms of analysing
| results.
| badpun wrote:
| > I am fairly sure there are multiple published results in
| computational fluid dynamics that are subtly wrong.
|
| I wonder what that means for the accuraccy of the climate
| models...
| sd2022al wrote:
| Very nice summary paper on FEM! FEM has now become a key part of
| any physical product development process. I used to work in FEM
| area and few years back switched to unrelated software domains -
| so felt a bit of nostalgia reading the paper. Thanks for posting
| !
| kwkelly wrote:
| I just skimmed this and I never worked in FEM but this really
| brought me back. I had the pleasure of meeting several of the
| people in the article (Hughes, Oden, Babuska, Demkowicz) and
| couldn't help feeling some nostalgia as well.
| cpp_frog wrote:
| Great! Hughes, Oden and Babuska are three of my heroes. My
| work is in FEM, specifically, the theory of Mixed Finite
| Elements and Eigenalue problems, to which both Babuska made
| important contributions. Oden I know from elasticity for the
| most part.
| rpep wrote:
| My favourite resources for FEM were the book and courses that
| Hans Petter Langtangen (RIP) wrote at Simula. FEniCs made FEM so
| easy, it's truly an excellent software project that is
| unfortunately not as well known as it should be within the
| community.
|
| http://hplgit.github.io/num-methods-for-PDEs/doc/web/index.h...
|
| http://hplgit.github.io/num-methods-for-PDEs/doc/pub/index.h...
| laingc wrote:
| Used it in its infancy for my PhD work - absolutely loved it,
| despite its teething problems. Also +1 for Langtangen!
| pclmulqdq wrote:
| My numerical analysis professor once told the class a story about
| how he used the finite element method to solve stresses on pieces
| of metal for the soviet space program. Computers were too
| expensive, so they did it by hand.
|
| They cleared a university classroom of all the chairs and desks,
| and rolled out pieces of paper to cover the floor. The team took
| their shoes off proceeded from one corner of the room to the
| other. If you found that someone had made a mistake, you had a
| record available to find it, and you could simply rip up the
| paper at the point where the mistake was made and roll out fresh
| paper to take its place.
|
| Apparently a triangle took a few days.
|
| SolidWorks does the same math today.
| mkoubaa wrote:
| I still work on FEA and it's as technically interesting as ever
| TheRealPomax wrote:
| A Springer publication that's free instead of a hyper-inflated
| price to extrort academia for just past what it can afford? What
| year is it?
| revskill wrote:
| I'm not sure if there's a simple implementation of FEM (might be
| < 50 lines of code) to understand the virtual of the algorithm
| then.
| buescher wrote:
| You can do it in excel. I don't have a particularly good
| example.
| mazokum wrote:
| You can check this paper. Is the one my advisor recommended
| when I started my PhD. Is a FEM implementation in 50 lines of
| MATLAB.
|
| https://www.math.hu-berlin.de/~cc/cc_homepage/download/1999-...
| shoo wrote:
| What I found amazing about FEM is not the detail of how to
| implement it in code, but all the PDE theory & approximation
| theory -- how you can express the original continuous-domain
| infinite dimensional problem in a weak form using an infinite
| dimensional space of test functions, then approximating the
| weak form of the original problem with a finite dimensional
| Galerkin approximation, using a finite dimensional space of
| test functions, and use that to define a finite dimensional
| system of equations to solve. Then the theory for under what
| conditions you can guarantee that approximate solutions
| obtained from your finite dimensional approximation converge
| toward the true solution, as you increase the mesh
| resolution, and how fast the convergence rate will be.
|
| Some of this is summarised in this paper in 2. model problem
| & 3. Galerkin discretisation of the problem, but not in a way
| that will communicate the mathematical ideas to anyone who
| hasn't already taken a course on the theory -- probably need
| a couple of courses on real analysis & a course on PDE as
| pre-reqs.
| mjhay wrote:
| The algorithm for linear PDEs usually boils down to some kind
| of meshing/discretization (often the hard part) to make a
| (usually sparse) linear system to solve using standard
| numerical methods. In the basic 1d, first-order case, it winds
| up being exactly the same thing as equivalent finite difference
| method.
| MichaelZuo wrote:
| Thanks for posting! Reminds me of long night spent fussing over
| ANSYS models.
| netman21 wrote:
| This is great. I studied FEM in school and got my first job in
| industry as a structural analyst. I started my own firm when I
| was 25 and employed 22 analysts that I contracted to Pontiac
| Motors.
| Scramblejams wrote:
| Former structural analyst here. :waves: If you worked on
| consumer products there (aka cars and their components), do you
| happen to remember what the design-to fatigue life was? I
| talked with another analyst several years ago who had worked at
| Chrysler, and he told me they had used 125,000 miles. (I was in
| aerospace so not sure how many miles comprised a fatigue cycle,
| etc.)
| auxym wrote:
| Not exactly what you asked, but:
|
| I worked as a structural analyst on passenger train cars
| (metros, LRVs, etc) for a while, as my first job after grad
| school actually.
|
| Depending on the project (client requirements), we designed
| for 25-35 year lifetimes, with 12-24h operation typical. That
| usually amounted to millions of kilometers.
|
| We had load cases with varying numbers of cycles. Eg curves
| with light loading might have been millions of cycles, but
| max (or even over max) loading might have been 10s or 100s of
| thousands of cycles.
|
| All load cases were determined based on on usage stats from
| the operator and testing conducted to measure accelerations
| on the operator's infrastructure.
___________________________________________________________________
(page generated 2022-11-05 23:00 UTC)