[SciPy-dev] the scipy mission, include finite element solver

Ondrej Certik ondrej@certik...
Wed Apr 8 17:43:30 CDT 2009


On Mon, Apr 6, 2009 at 11:56 AM, Cohen-Tanugi Johann
<cohen@lpta.in2p3.fr> wrote:
> Sorry to jump on this (interesting) discussion with a relevant question
> but aside from Ondrej initial question : is there somewhere a scipy
> mission statement clearly spelled out?

I would like to know this too. Seems like people differ in the
interpretation of the mission.

Let me reply to the points above:

On Mon, Apr 6, 2009 at 2:16 AM, Benny Malengier
<benny.malengier@gmail.com> wrote:
> As a user, I would very much like to see scipy include some FEM base.
> As you say, a generic framework would allow others to just write a different
> core, support other mesh formats, ..., eg they could be done as scikits.
> The fragmentation now is large.

Exactly.

>
> I am using freefem++ (http://www.freefem.org/ ) recently for quick reference
> solutions in 2D. Would you plan such a high level parsing of weak forms?

Yes, we do --- we just want to use Python+Cython to enter the forms.



On Mon, Apr 6, 2009 at 2:23 AM, Prabhu Ramachandran
<prabhu@aero.iitb.ac.in> wrote:
> On 04/06/09 03:15, Ondrej Certik wrote:
>> the mission of scipy from scipy.org:
>>
>> "
>> SciPy is open-source software for mathematics, science, and
>> engineering. [...] The SciPy library [...] provides many user-friendly
>> and efficient numerical routines such as routines for numerical
>> integration and optimization.
>> "
>>
>> it has solvers for ODEs using several methods. Is having a finite
>> element (FEM) solvers for PDEs (and some ODEs too) among the scipy's
>> goals?
>
> I do not think this would fit in with the purposes of scipy the library,
>  for the next obvious question would be what about grid generators?
> What about finite difference and finite volume solvers and so on.  I
> think these are a little too specialized to go into scipy proper.  There
> are a plethora of approaches, techniques, algorithms and a host of
> problems with each.

There could be one good enough default mesh generator in scipy. As to
FDM -- imho FEM is much more versatile and general. As to FVM, imho
many aspects of FVM could be handled by such an interface as well.

Besides, I propose to add adaptive FEM, so the mesh generator is only
really needed to define the geometry, which in lots of cases can be
done even by hand, as the solver takes care of the rest.

>
> A scikit would be good as would a separate family of tools under the
> scipy umbrella.  It would be great to have a scipy-pde package but what
> does this have to do with scipy itself?  Do we have a larger

So what exactly is "scipy itself"? I thought it could be all numerical
things, that are in matlab.

They have it as a toolbox:

http://www.mathworks.com/products/pde/

so I guess scipy should be like a bare matlab and all toolboxes should
go to scikits?

> super-package that hopes to provide different bundles, kind of like sage
> but more targeted to numerical computing?

What do you mean by "we have a larger superpackage"? Are you asking if
we want to have such a package, or if we want scipy to become such a
package?

>
>> Together with a project like SPD:
>>
>> http://code.google.com/p/spdproject/
>
> Perhaps this is really the answer.  A specialized set of sub-packages or
> bundles with SPD for different tasks.

Yes, that's what we'll do most probably.



On Mon, Apr 6, 2009 at 8:58 AM, Daniel Wheeler
<daniel.wheeler2@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 5:23 AM, Prabhu Ramachandran
> <prabhu@aero.iitb.ac.in> wrote:
>
>> I do not think this would fit in with the purposes of scipy the library,
>>  for the next obvious question would be what about grid generators?
>> What about finite difference and finite volume solvers and so on.  I
>> think these are a little too specialized to go into scipy proper.  There
>> are a plethora of approaches, techniques, algorithms and a host of
>> problems with each.
>
> Totally agree. Scipy should be low level, FE tools etc should be using
> scipy/numpy not integrated into scipy.
>
> One weakness right now is that there doesn't seem to be a good open
> source python based meshing tool. Again, this is not something that
> should necessarily be in scipy, but something that should probably
> leverage from scipy. We (FiPY) currently use gmsh, but it is not
> tightly integrated and and we've written our own standard mesh
> classes, but haven't done anything more with this.

I like the FiPy project, when I get more time, I'd like to create some
unified interface, so that one can take one equation and solve it with
both FiPy and our FEM code (or libmesh), so that one can compare all
those solvers and see which one performs the best.

Can FiPy do adaptive mesh refinement? I was trying to find it in the
manual, but it seems you always need to create the mesh beforehand?
Then you calculate on it, you get something. How do you know if it's
precise enough and if you should refine the mesh? How do you determine
where you should refine it and how much?

If our FEM solver creates a nice hp mesh automatically, imho you
cannot beat it by any hand made mesh, so then any comparison with a
hand made mesh would be unfair to fipy.

Ondrej


More information about the Scipy-dev mailing list