dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Feb 03, 2005 at 06:53:53PM +0100, Johan Jansson wrote:

> The assembly looks like it's working now in the scalar case, the
> vector case is still left to look at.

Good, I'll see if I can find time to fix the bug in FFC for systems.

> > 1. A user should be able to give one ore more NewFunctions as
> > arguments to the solver (module). What should the interface of a
> > module be? The simplest and probably most flexible would be that each
> > solver provides a static function named solve() that takes the
> > arguments that are needed, for example:
> > 
> > PoissonSolver::solve(mesh, f, TOL, ...);
> 
> Yes, this looks like a simple solution.

ok good. Then we can also remove all the code for the common solver
interface: Problem, Solver, scanmodules.sh, poisson.module etc...

Simpler is probably better in this case. The interface of the ODE
solver is of this type (does not go through the common interface if
the wrapper is not used) and it makes everything much more flexible.

> > 2. How should we implement user-defined functions? Is it possible to
> > create a virtual function in NewFunction that can be overloaded?
> > 
> > class MyFunction : public NewFunction
> > {
> >   real operator() (const Point& p) { return sin(p.x*p.y); }
> > }
> > 
> > MyFunction f;
> > 
> > I think it's better to overload operator() than passing around
> > function pointers.
> 
> Ok. As I think we've discussed before, function evaluation will
> probably not be critical, so this sounds like a solution which will
> make life simpler.

Good. There is already a check in NewFunction::project() if the given
function is defined on the same mesh. For a user-defined function, the
else case can just call NewFunction::operator() (const Point& p) for
the current point to get the value.

> > 3. NewGMRES::solve() should be made static.
> 
> Why is this necessary? If it's static, then NewGMRES can't store any
> parameters etc., and everything will need to be passed to solve every
> time.

Is there a way to support both cases? Sometimes you want to reuse the
GMRES solver and other times when you just need to solve a system it
seems simpler to just do GMRES::solve().

Could the static version just create an object and then call solve on
that object?

/Anders