Subject: [UFC-dev] [HG ufc] Add sub domain argument to form::create_foo_integral()

From: [email-masked] (UFC)
Date: Mon, 22 Jan 2007 18:48:43 +0100 (CET)

One or more new changesets pushed to the primary UFC repository.
A short summary of the last three changesets is included below.

changeset:   85:bd1686daf0a0b12547b2b80a1b6d87447883e23b
tag:         tip
user:        "Anders Logg <[email-masked]>"
date:        Mon Jan 22 18:48:40 2007 +0100
files:       src/ufc/ufc.h src/utils/python/ufc/form.py
description:
Add sub domain argument to form::create_foo_integral()

changeset:   84:34919c24a619aa7397f6ac6f25db8fa79831246c
user:        "Anders Logg <[email-masked]>"
date:        Wed Jan 17 13:54:43 2007 +0100
files:       src/utils/python/ufc/finite_element.py
description:
Remove misplace "= 0" in code generation template.

changeset:   83:8cc369fe54f24e5dd920b5158837a11b6ed1a2a1
user:        "Anders Logg <[email-masked]>"
date:        Wed Jan 17 13:53:20 2007 +0100
files:       src/utils/python/ufc/finite_element.py
description:
Remove misplaced ";" in code generation template for create_sub_element()

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ufc

---

From: Anders Logg <[email-masked]>
Date: Mon, 22 Jan 2007 19:58:51 +0100

On Mon, Jan 22, 2007 at 07:49:15PM +0100, Martin Sandve Alnæs wrote:
> On 1/22/07, UFC <[email-masked]> wrote:
>    /// Create a new cell integral on sub domain i
>    virtual cell_integral* create_cell_integral(unsigned int i) const = 0;
> 
> Does this belong in the interface? Why not leave this up to the
> assemblers discretion, and just use one form for each sub domain? Does
> this solve any particular problems?
> 
> martin

It is not strictly necessary, but it seems natural. Right now, the UFC
form represents something like

    a(v, u) = ... *dx + ... *ds + ... *dS

where dx is integration over a domain Omega, ds is integration over
the boundary of Omega and dS is integration over the interior facets
of Omega.

It seems natural to not limit the representation to exactly three sub
domains but instead support arbitrarily many terms of each kind.

It is not strictly necessary to have this but the difference is just
adding one argument to create_*_integral() where there previously was
no argument.

/Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Mon, 22 Jan 2007 20:11:57 +0100

> adding one argument to create_*_integral() where there previously was

Ok.

Does dolfin::Mesh have support for defining subdomains? And boundary
subsections? I'll need this soon in the PyCC::FEMAssembler.

martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 22 Jan 2007 20:20:47 +0100

> subsections? I'll need this soon in the PyCC::FEMAssembler.

Not yet, but this will be supported through the MeshFunction class
which can be used to mark sub domains. Kalkulo have also recently
developed a graphical mesh editor for DOLFIN meshes (that I hope can
be released soon). This can then be used to mark sub domains.

/Anders

---

From: "Johan Hoffman" <[email-masked]>
Date: Tue, 23 Jan 2007 09:15:34 +0100 (MET)

> adding one argument to create_*_integral() where there previously was

Great to see that you are incorporating this in your work plan! I think it
is natural to allow integration over arbitrary subdomains in the form,
this arises in many situations. It is also very natural in terms of using
FFC for postprocessing.

/Johan

>
> /Anders
> _______________________________________________
> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev
>

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 24 Jan 2007 15:41:16 +0100

> >>    virtual cell_integral* create_cell_integral(unsigned int i) const =

But what is the meaning of "subdomain i"? In particular for
boundaries, it could mean the boundary of subdomain i or just boundary
part i? Maybe we should just leave that completely undefined?

I could technically use this to define f.ex. computation of the stress
tensor as "cell integral 2" of a form, although it is meant for a
postprocessing step, is that ok?

martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 24 Jan 2007 21:41:32 +0100

> part i? Maybe we should just leave that completely undefined?

I think the natural thing is that for a cell_integral, then it is
sub domain i, for an exterior_facet_integral, it is sub boundary i,
and for an interior_facet_integral, it is sub domain i.

> postprocessing step, is that ok?

Yes, why not. The UFC specification does not care how you use the
code. The assembler decides what to do with the generated code so it
is a matter between you and your assembler... :-)

/Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Thu, 25 Jan 2007 19:30:43 +0100

> is a matter between you and your assembler... :-)

Then all boundary condition forms and post processing forms can be
made part of the same ufc, which I guess can be convenient. But on the
other hand it doesn't quite fit the name "form" then.

martin

---

From: Anders Logg <[email-masked]>
Date: Thu, 25 Jan 2007 20:11:44 +0100

> other hand it doesn't quite fit the name "form" then.

Even if you can throw all forms into a single form, it is probably
more natural to generate separate forms for postprocessing. For
example, it is natural to define forms with only one argument (to be
assembled into a scalar) for computation of functionals of a computed
solution, such as the lift or drag.

Also note that it is only natural to put to forms into a single form
if they share everything else: same finite elements, dof maps,
argument functions etc, which may not always be the case for two forms
where one is for the variational problem and the other for
postprocessing.

/Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Fri, 26 Jan 2007 09:47:37 +0100

> where one is for the variational problem and the other for

Yes. So multiple kinds of boundary conditions will probably be the
most common usage of this.

martin