dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Tue, Feb 01, 2005 at 10:59:52AM -0600, Anders Logg wrote:
> I have updated FFC to do the following:
> 
> 1. Generate tensodims() correctly for tensor-valued elements
> 2. Generate dof() correctly for vector-valued elements
> 3. Generate code for initialization of functions
> 
> I have modified the DOLFIN interfaces (*Form) to match the new
> version of FFC. I also did some cleanup of the assembly.
> 
> Everything should now be in place, but it seems some debugging of the
> assembly is necessary. Is someone willing to take a look? The test
> example I have used is the Poisson module.
> 

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

> Functions should work like this:
> 
> 1. NewFunctions are given as arguments to the constructor of the form:
> 
>    Poisson::LinearForm L(f);
> 
> 2. FFC automatically generates code for initialization of each function:
> 
>     init(1, 3); // One function, space dimension is 3
>     add(w0);    // See below
> 
> 3. Each added function corresponds to a list of coefficient in the
> element basis. When Form::update() is called from the assembler,
> the coefficients of each function are updated by computing
> the projection to the current element:
> 
> void Form::updateCoefficients(const Cell& cell, const
> NewFiniteElement& element)
> {
>   dolfin_assert(nfunctions == functions.size());
> 
>   // Compute the projection of all functions to the current element
>   for (uint i = 0; i < nfunctions; i++)
>   {
>     dolfin_assert(functions[i]);
>     functions[i]->project(cell, element, c[i]);
>   }
> }
> 
> Some things we need to think about:
> 
> 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.

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

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

  Johan