dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 17, 2009 at 04:29:41PM +0000, A Navaei wrote:
> 2009/2/17 Anders Logg <logg@xxxxxxxxx>:
> > On Tue, Feb 17, 2009 at 04:12:15PM +0000, A Navaei wrote:
> >> 2009/2/17 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.
> >>
> >> I'm a bit confused here. The pre-compiled elements and the signatures
> >> are going to be removed, avoiding these, are there any other ways of
> >> creating Functions in c++?
> >
> > Yes, as I suggested earlier: compile the function space and include
> > the code.
> 
> I thought the above is the same as the 'pre-compiled' approach as
> Garth suggested. Now I assume that pre-compiled means the ones in
> dolfin/elements/ffc_*.h.
> 
> 
> -Ali

Yes!

I mean dolfin/elements/ffc_*.h and ElementLibrary::create_foo.
It's somewhat of a remnant from pre 0.9 that might be removed when
we've figured out how to replace it.

It's easier and safer to define your own FunctionSpace classes (using
your own naming convention) and just include the generated code.

-- 
Anders

Attachment: signature.asc
Description: Digital signature