On Tue, Feb 17, 2009 at 04:12:15PM +0000, A Navaei wrote: > 2009/2/17 Anders Logg <[email protected]>: > > On Tue, Feb 17, 2009 at 03:55:58PM +0000, A Navaei wrote: > >> 2009/2/17 Anders Logg <[email protected]>: > >> > 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. -- Anders > > -Ali > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > > > iEYEARECAAYFAkma36AACgkQTuwUCDsYZdGYXgCfYvfjJu9MqY9eJa1eLWHhzYFO > > M2AAnjI2rhfbameeqNL7lsfZnifVKaVO > > =VmfI > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > DOLFIN-dev mailing list > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
