dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 17, 2009 at 03:55:58PM +0000, A Navaei wrote:
> 2009/2/17 Anders Logg <logg@xxxxxxxxx>:
> > On Tue, Feb 17, 2009 at 03:28:08PM +0000, Garth N. Wells wrote:
> >>
> >>
> >> A Navaei wrote:
> >> > The following minimal test for Function in c++ reveals some bugs. I
> >> > guess this example can help me with dealing with the current issues of
> >> > ImageFunction.
> >> >
> >> > (1) interpolate.py does not work when a Function is created in c++ and
> >> > wrapped (see comment [2]). It seems that the bug is originated from
> >> > the copy constructor (see comment [3])
> >> >
> >> > (2) In order to perform the interpolation, why is it necessary to
> >> > create another Function and then copy it?
> >> >
> >> > (3) Signature checkes seem not working properly (see comment [1]). The
> >> > signature-based assignments are error-prone anyway, why the
> >> > object-oriented approach is not used?
> >> >
> >>
> >> Signatures are used to permit reading/writing Functions to a file. They
> >> are indeed error prone, so I believe that we reached a consensus a short
> >> while ago that we would remove pre-compiled elements.
> >>
> >> Garth
> >
> > Instead of signatures, I'd recommend that you define a simple form
> > file for each of the different types of FunctionSpace you need, for
> > example:
> >
> >  element = FiniteElement("CG", "triangle", 1)
> >
> >  v = TestFunction(element)
> >  u = TrialFunction(element)
> >  a = v*u*dx
> >
> > If you put this in a file named My.form and compile it with FFC using
> > -l dolfin, you will get a class named MyFunctionSpace that you can
> > then instantiate using just a mesh:
> >
> >  MyFunctionSpace V(mesh);
> >
> > Create one form file for each of the different types of FunctionSpace
> > that you need, name the files to something suitable and use the
> > generated code. That way you won't need to worry about signatures,
> > dofmaps and finite elements.
> 
> Maybe this should be provided in the main library with a global
> access, as this is not specific?
> 
> A more robust way, which does not need code generation, is simply
> defining the available options as types in an enum or struct. In this
> way, in both python and c++ we can have the form-like style:
> 
> element = FiniteElement(ElemBasisType.CG, ElemGeoType.Triangle, 1);
> 
> which is error-safe.
> 
> Any comments on the main subject?

As Garth says, we might be removing the precompiled elements and
initialization from signatures in future releases so it's best not to
use it.

-- 
Anders

Attachment: signature.asc
Description: Digital signature