dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Aug 23, 2005 at 08:28:32PM +0200, Garth N. Wells wrote:
> Attached are some patch files which, if they could be added to Dolfin, would be
> really useful for me. They involve:
> 
> 1) Time-dependent boundary conditions (BoundaryCondtion.cpp_patch
> and BoundaryCondtion.h_patch). I've done this in the same way as
> it's done for a function. It might be nice in the future if the time
> could be more globally available.

One possibility would be to add the time as an argument to operator()
in BoundaryValue:

    virtual const BoundaryValue operator() (const Point& p, real t);

but that would require FEM::assemble() to know the time.

The current implementation (your patch) has the advantage that it
works in the same way as the Function class. In both cases, a Function
or a BoundaryValue represents a field on a mesh at a given time
t. It's not a function of time, but rather a sample at a given time so
the user needs to explicitly change the time.

> 2) Computing eigenvalues of a matrix directly using PETSc
> (GMRES.cpp_patch and GMRES.h_patch). The function replaces the usual
> "solve". It solves the system and returns n eigenvales in two
> Vectors - one for the real component and one for the complex
> component. I haven't added a version for virtual matrices.

I think this looks a little strange, a function that both solves the
system and computes eigenvalues. Looks like these two computations are
carried out independently, so maybe they should be two separate
functions?

Maybe a new class for computing eigenvalues?

A related question: should we put some shortcuts for some of the basic
operations in the dolfin namespace, like

  dolfin::solve(A, x, b)
  dolfin::eig(A, l, n)
  dolfin::assemble(a, A, mesh)

or should we add easy access as member functions:

  A.solve(x, b)
  A.eig(l, n)

Or both?

/Anders