dolfin team mailing list archive

[A Navaei <axnavaei@xxxxxxxxxxxxxx>]

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

>
> --
> Anders
>
>
>>
>> -Ali
>>
>> >
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.9 (GNU/Linux)
>> >
>> > iEYEARECAAYFAkma36AACgkQTuwUCDsYZdGYXgCfYvfjJu9MqY9eJa1eLWHhzYFO
>> > M2AAnjI2rhfbameeqNL7lsfZnifVKaVO
>> > =VmfI
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > DOLFIN-dev mailing list
>> > DOLFIN-dev@xxxxxxxxxx
>> > http://www.fenics.org/mailman/listinfo/dolfin-dev
>> >
>> >
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkma5LwACgkQTuwUCDsYZdGbkgCffZaURqMV8P56FHJzT36glSiy
> 66IAnRxqG4YPY0pMiwIZOq8bzL2gtSQC
> =A7JQ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>