GSL and PDE's
Mon Mar 24 14:03:00 GMT 2003
* Brian Gough <firstname.lastname@example.org> [030322 19:58] schrieb:
> James Haefner writes:
> I think it's beyond the scope of GSL, unless someone has a good way to
> handle all the possible types of PDEs.
Lets make a few restrictions.
Lets talk only about 2d-areas and it should be possible to solve a
large number of PDEs by using finite element methods. IMHO most PDEs
of the style
- \eps * \Laplace u + k \cdot \nabla u + r u = f
u=g on the edge of Omega (\subset R^2)
could be solved. If |k|>>eps you have to deal with some problems to
stabilise the finite elements but there are some techniques to do that.
And there are some problems if k=0 r<0 for some values of r,
but this would go to far...
Time depends can be handled by using implicit ODE solvers over
the results of static PDEs.
One problem is that the GSL has no implementation of sparse matrices
and solvers for large sparse linear equation systems. There are missing
most of the components to implement finite element methods.
you need :
- a mesh generator
- sparse matrices
- some assembling routines
- solvers for sparse matrices like cg and/or gmres
Some free mesh generators can be found on the web and assembling
routines are quite fast written. A good sparse matrix lib and
good solvers are very important and not that easy.
Nevertheless you may need some adaptive methods to refining
you mesh, if this is needed. In fact I think this and the
solvers are the things that require a lot of work.
IMHO GSL is (sorry) right now not the best choice to do so,
because non of these things is implemented.
If you want, you can use GSL to program a mesh generator
or some of the solvers, e.g. gmres requires some
QR-factorisation of an upper Hessenberg-matrix.
Of course you can also use lapack and atlas...
Is there any interest in a Finite-Element-PDE-Packet based on/for GSL?
Depending on the goals of such a packet I would like to help
Have a nice day,
Fachbereich 6 - Mathematik
More information about the Gsl-discuss