← Back to team overview

dolfin team mailing list archive

Re: assembly and boundary conditions

 

Anders Logg wrote:
On Wed, Mar 21, 2007 at 02:46:48PM +0100, Garth N. Wells wrote:
For the new assembly, should we create a new class for applying Dirichlet boundary conditions? Alternatively, we could add functions to BoundaryCondition to do the job.

Yes, why not, but how do we want to specify boundary conditions?

There are some options:

   MyBoundaryCondition bc;
   bc.apply(A, b);

or

   assemble(A, b, ..., bc):


I prefer the latter as it allows for restrained degrees of freedom to be eliminated from the system, rather than zeroing rows. While not a high priority, I'd like to have this in the future.

Should BoundaryCondition posses the members functions to apply the boundary conditions? I'm reluctant to add these to Assembler in order to keep Assembler clean and just for assembly.


Also, for the new assembly, is there anything other than boundary conditions and updating of functions that needs to be done before it's usable?

I think that's it for the basic functionality of assembly. Then there
is the question about how we want to design the interface.

Right now, FFC (new UFC-based) generates one .h file for each .form
file and each .form file can contain exactly one form, which must have
the name 'a'.
Take a look at the following lines, this is what we have now:

1. Poisson.form (form file)

    a = dot(grad(v), grad(u))*dx

2. Poisson.h (generated with ffc -l ufc Poisson.form)

    class Poisson: public ufc::form
{ ...
    }

3. main.cpp (includes generated header file)

    #include "Poisson.h"

    ...

    Poisson poisson;
    assemble(A, poisson, mesh);

We have a few things to settle (which we could do pretty quickly):

1. Is the principle one form file - one form ok? Or do we want to be
able to define several forms in one file (a, L and M)?

With one form per file, we would have PoissonBilinearForm.form and
PoissonLinearForm.form and then

    #include "PoissonBilinearForm.h"
    #include "PoissonLinearForm.h"

    PoissonBilinearForm a;
    PoissonBilinearForm L;


I prefer having multiple forms in one file.

2. How do we want to attach fixed functions to forms, like the
right-hand side in Poisson? Before, we had

    Function f;
    PoissonLinearForm L(f);

The problem with this is that FFC now generates UFC-compliant code
(only including the ufc.h header). It does not include anything from
DOLFIN (like Function.h) which would be necessary for this to work.

One option that I've been thinking of is to have an option to FFC
-l dolfin, which would generate UFC code and at the end insert code
that wraps the UFC form in a DOLFIN Form:

    class PoissonLinearForm_UFC : public ufc::form
    {
      ...
    };

    #include <dolfin/Function.h>
    #include <dolfin/Form.h>
    class PoissonLinearForm : public dolfin::Form
    {
    public:

      PoissonLinearForm(Function& f) : Form(1)
      {
          init(0, f);
      }
};

Opinions?


Not sure what's best here. I like the above approach as nothing changes on the DOLFIN side, but it does require FFC to be more than just UFC compliant.

Garth

/Anders
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev





Follow ups

References