fenics team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Johan Jansson <johanjan@xxxxxxxxxxxxxxxx> writes:

      More than 50% of Petsc downloads (we estimate) are for the
Windows version, which we also surmise is not a supercomputer. There
is no difference in our application code that runs on a supercomputer
from what I run on my laptop. In fact, I do all development on the
laptop, and only move to the supercomputer for VERY large runs (the
overwhelming amount of supercomputer usage is robbery of the taxpayer).

      The above paragraph is meant to support the thesis that there
need not be any difference between development for a laptop and a
supercomputer. In my view, parallelism is recognition of structure
inherent in the problem. Witness the difference between "parallelism"
in densse and sparse linear algebra. They bear almost no relation to
each other. In fact, the parallelism in sparse linear algebra has the
same root as parallelism in FEM. This point is made forcefully in the
Sieve paper.

      Thus, I would be interested in any aspect of FENICS software that:

  1) Makes it hard for a laptop user to code/run

  2) Prevents it from running on a supercomputer

I do not see antagonism between these goals.

  Thanks,

        Matt

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

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness