fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Let me also point out that Johan has done a great job with the FEniCS
component Ko, which sits on top of DOLFIN/FFC and provides a
domain-specific interface and utilities for simulating mechanical
systems that could be used in animation, gaming etc.

We could have more domain-specific interfaces that target specific
application areas.

/Anders

On Tue, Sep 27, 2005 at 11:03:45AM +0200, Johan Jansson wrote:
> Hi!
> 
> I think it's a very nice discussion going on right now, many good
> points. I just want to make an addition with a slightly different
> perspective.
> 
> The application domain we seem to be discussing is scientific
> computing on supercomuters, i.e. the target "customer" for Fenics is a
> scientist at some lab with a supercomputer.
> 
> I think this view is far too limited, but I guess is a symptom of the
> particular academic environment most of us live in. PDEs and the need
> for discretization appears in computer games, image manipulation,
> video processing, computer animation, medical training simulators,
> flight simulators, etc. etc. Some of these involve supercomputers, but
> some do not. The vision algorithm for a robot probably runs on an
> embedded system, but likely involves discretizing a PDE (or at least
> could be modeled as one). There's no reason Fenics should not be used
> to generate the code for that algorithm.
> 
> What is common for all these application domains however is the need
> for efficiency and the need for conceptual abstraction (I don't think
> a developer of a filter for the Gimp or Photoshop wants to worry about
> the details of a finite element solver). I believe Fenics solves both
> of these in a very nice way. The input is the form and the element(s),
> I can't think of a better abstraction representation, and we can
> generate an optimal solver from that completely automatically.
> 
> Of course supercomputers are important, and of course parallelism is
> important, the embedded system in the robot could probably be parallel
> as well. What I'm saying is, let's not tailor Fenics only for
> scientists with supercomputers, and in doing so, sabotage Fenics for
> other application domains. I believe historically this has been true,
> FEM "codes" have been specifically tailored for supercomputers, and
> this has limited the spread of the FEM into other domains. If you ask
> a typical engineer what the FEM is, he will say that it's a method for
> dividing a domain into triangles. As far as I know, the mechanical
> engineers at Chalmers don't come into contact with the FEM unless they
> specifically choose that track.
> 
> We have the opportunity to create a FEM system which can generate
> optimal solvers for essentially _all_ domains. We can solve the
> accessibility problem of the FEM, which is the complexity explosion of
> coefficients and indices once and for all and actually make it
> available to normal people (engineers at least), without having to
> sacrifice _any_ performance. Or perhaps we should say that "we have
> already solved" this problem (with regards to assembly at least), now
> it's essentially a question of packaging and further developing it.
> 
>   Johan
> 
> _______________________________________________
> fenics-dev mailing list
> fenics-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/fenics-dev
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/