dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Friday 15 May 2009 13:37:48 Anders Logg wrote:
> There have been some big changes to the code lately. Here's a summary:
>
> 1. We now use the wrappers module in dolfin_utils to generate the
> DOLFIN wrapper code (in both FFC and SFC). This module generates
> slightly different code to the old FFC wrappers. Most notably,
> typedefs are used to avoid code duplication and classes/namespaces are
> now nested. For application code, that means one must change from
>
>   PrefixBilinearForm
>   PrefixLinearForm
>   PrefixTestSpace
>   PrefixTrialSpace
> to
>
>   Prefix::BilinearForm
>   Prefix::LinearForm
>   Prefix::BilinearForm::TestSpace
>   Prefix::BilinearForm::TrialSpace
>
> etc.
>
> If all test and trial spaces are equal, then a common class named
>
>   Prefix::FunctionSpace
>
> will be created (a typedef).
>
> Some of you may remember that we've had this interface before, but
> then had to remove it due to problems with SWIG. Now that SWIG just
> looks at the pure UFC code it's not a problem anymore.
>
> 2. Initialization of mesh entities now happens in the constructor of
> DofMap. The initialization happens automitcally only if the new
> non-const (wrt Mesh) constructor of FunctionSpace is used. If the
> const version is used, then an error message is given. So if you solve
> something with P2 elements and need the edges, these must either first
> be generated using mesh.init(1) or the non-const constructor must be
> used. Most demos should remain unchanged.

As swig does not distinguish between const and non const parameters this 
results in an overload warning. This is easely fixed, by an ignore statement. 
Just to be sure I do the right thing here, the right constructor to ignore is 
the const mesh one, right?

Johan

> 3. When running in parallel not only will the entities be generated,
> but they will also be numbered globally. So all mesh entities have a
> unique global index accessible in the data section of a mesh (named
> "global entity indices %d"). The global dof map should also be
> computed correctly now but I haven't checked. This means we may in
> principle assemble in parallel now. But probably not in
> practice... :-)