Subject: [FFC-dev] About signatures in FFC-generated dolfin::Form subclasses

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 3 Dec 2008 14:26:57 +0100

There is a signature:

  // Create form on given function space(s) with given coefficient(s)
(shared data)
  PoissonLinearForm(std::tr1::shared_ptr<const dolfin::FunctionSpace>
V0, dolfin::Function& w0) : dolfin::Form(), f(*this)

but no signature where both the function spaces and functions are
shared pointers. For an application with full use of shared pointers,
we need that.

(I'm looking at this now because I want to generate dolfin code from SFC).

--
Martin

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 3 Dec 2008 15:28:04 +0100

> (I'm looking at this now because I want to generate dolfin code from SFC).

Also, after trying to sketch an hyperelasticity solver in C++ dolfin
with the new function design, I'm considering generating typedefs
to FunctionSpace subclasses using function names like

FooForm::FunctionSpace_u, FooForm::FunctionSpace_Q,
FooForm::FunctionSpace_dt etc.

as well as using actual form names from the .ufl file for the
dolfin::Form subclass name:

%(prefix)sForm_%(uflformname)s

examples:

ElasticityForm_f
ElasticityForm_F
ElasticityForm_J
ElasticityForm_J_adjoint
ElasticityForm_J_action
...

ElasticityForm_f::FunctionSpace_u V(mesh);
Function u(V);

since a .ufl file should be able to contain many forms to reuse things
like element and function definitions, and stuff like material laws in
both equations and postprocessing forms etc.

--
Martin

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 03 Dec 2008 14:43:05 +0000

> shared pointers. For an application with full use of shared pointers,

I don't think that it's required. I brought this point up a while ago,

   http://www.fenics.org/pipermail/ffc-dev/2008-November/001923.html

and Anders clarified the situation and it made sense to me at the time 
(I checked by following through the code), although I agree that it's 
cryptic and counter-intuitive.

Garth

> _______________________________________________
> DOLFIN-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/dolfin-dev

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 3 Dec 2008 17:04:37 +0100

>  http://www.fenics.org/pipermail/ffc-dev/2008-November/001923.html

Quoting this:
"""
On Thu, Nov 06, 2008 at 08:14:47PM +0000, Garth N. Wells wrote:
> For the 'shared' versions, shouldn't the coefficients also be shared
> pointers?

It's not necessary since these arguments will not be stored as
data. They will just be assigned to the coefficients.
"""

That's just plain wrong. Through Coefficient::attach, the Form will
store shared pointers to them with NoDeleters, and these pointers
won't share the reference count of an eventual shared pointer I
have in my application.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 3 Dec 2008 17:56:45 +0100

> won't share the reference count of an eventual shared pointer I

Yes, that seems to be wrong.

Do you need shared_ptr only in the constructors or do you also want
shared_ptr for the assignment operator?

Is it possible to reuse the DOLFIN-wrappers from dolfinformat.py in
FFC? It would be practical if we could reuse the same code since it's
a bit messy to generate with all the different combinations of
constructors with and without shared_ptr etc. It would also increase
the chances for generating compatible code.

Perhaps it can be placed in UFC, say under src/utils/python/dolfin?
It could be a single function that gets the form name(s) as input, the
list of coefficient names etc so it would be independent of the
form-compiler.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 4 Dec 2008 10:44:27 +0100

> shared_ptr for the assignment operator?

An additional assignment operator would be nice.

> list of coefficient names etc so it would be independent of the

I'm not reusing that code because it uses some ffc specific
assumptions and there are things I don't find flexible enough.
In particular, I don't want to duplicate element code.
I'll keep my code with no dependencies, and then we
can see whether we can agree on how to reuse it.

--
Martin

---

From: Anders Logg <[email-masked]>
Date: Thu, 4 Dec 2008 12:02:26 +0100

> An additional assignment operator would be nice.

ok, just add it (see below).

> can see whether we can agree on how to reuse it.

Sounds good. If you find a good solution, I'll be happy to reuse it
for FFC, including the additional constructors.

-- 
Anders