Subject: [UFC-dev] UFC suggestions

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 06 Feb 2009 16:16:56 +0000

We're working on method which requires integration on arbitrary surfaces 
within element, and there are two modifications/extensions to UFC that 
would be very useful (i.e. would allow us to comply with UFC). The first 
is to change

   virtual unsigned int ufc::dof_map::local_dimension() const = 0;

to

   virtual unsigned int ufc::dof_map::local_dimension(ufc::cell& cell) 

                                                              const = 0;

since our local dimension depends on the cell.

The second function that would be useful is a generic integral class like

   class ufc::user_integral

which would/could have the tabulate function

   virtual void tabulate_tensor(double* A,
                                const double * const * w,
                                const cell& c0,
                                const cell& c1,
                                unsigned int facet0,
                                unsigned int facet1) const = 0;

This would also require a function

   unsigned int ufc::form::num_user_integrals() const = 0;

Any thoughts or opinions?

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Sat, 7 Feb 2009 15:00:36 +0100

> since our local dimension depends on the cell.

Evt.

  virtual unsigned int ufc::dof_map::local_dimension(ufc::cell& cell) const
  { return local_dimension(); }

for compatibility.

Is this really the only place that needs changing to support variable
local dimensions?

> Any thoughts or opinions?

I don't quite understand, how is this different from the existing
interior_facet_integral?

If you want arbitrary surfaces within one element, why does this
signature provide two cells and their facets?

Martin

---

From: "Garth N. Wells" <[email-masked]>
Date: Sat, 07 Feb 2009 14:13:07 +0000

>> since our local dimension depends on the cell.

What does Evt. mean?

> Is this really the only place that needs changing to support variable

It is in our case, but that doesn't mean that it will generalise.

> I don't quite understand, how is this different from the existing

I've thought more about this class and I think that we can get away 
without it.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Sat, 7 Feb 2009 15:28:04 +0100

>>> since our local dimension depends on the cell.

eventually

> It is in our case, but that doesn't mean that it will generalise.

Ok.

> I've thought more about this class and I think that we can get away without
> it.
>
> Garth

Ok.

Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 10 Feb 2009 17:00:46 +0100

> Any thoughts or opinions?

We've discussed this in the past:

  http://www.fenics.org/pipermail/ufc-dev/2008-August/000539.html

What was discussed then was to add something like evaluate_integrand
to allow dynamic evaluation of the integrand at any given quadrature
point to allow user-defined integration over non-standard domains.

However, we've been considering a different approach that would
potentially remove the need for this. When we cut a mesh (by another
mesh or a crack) then one may triangulate the parts of the cut mesh
that were cut so that one will only need to consider integration over
triangles/tetrahedra.

The plan is for IntersectionDetector to automatically construct and
return the triangulation of the overlap of two meshes. See
new_intersection() and compute_polygon() in IntersectionDetector.cpp.

-- 
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 10 Feb 2009 16:06:56 +0000

> that were cut so that one will only need to consider integration over

Yes, we have already done this,

Garth

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

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 12 Feb 2009 19:36:31 +0000

>> It is in our case, but that doesn't mean that it will generalise.

I'd like to keep this discussion going because I'd like our code to be 
UFC-compliant and to work with the DOLFIN assembler. We currently can't 
do this.

What we need inside dof_map::local_dimension is the cell number, which 
we can extract from ufc::cell. Something like

     dof_map::local_dimension(unsigned in i)

would work for us, but

     dof_map::local_dimension(ufc::cell& c)

dovetails with other ufc::dof_map member functions that take a ufc::cell 
as an argument.

Garth

---

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 13 Feb 2009 12:23:19 +0000

[email-masked] wrote:
>>>>>>                                                             const =
>>>>>> 0;
>>>>> const
> I think this looks fine.

Any other opinions? I'd really like to have this functionality as soon 
as possible.

Garth

> Kent

---

From: Anders Logg <[email-masked]>
Date: Sun, 15 Feb 2009 21:35:20 +0100

> dovetails with other ufc::dof_map member functions that take a ufc::cell 

I think there are two options:

1. We sit down and figure out a more general solution for what
functionality might be needed for meshes which may possibly have
different local function spaces on different cells.

In addition to local_dimension(), there are several other functions in
dof_map that would need to be extended with a cell argument:

  needs_mesh_entities
  num_facet_dofs
  tabulate_facet_dofs
  tabulate_entity_dofs

2. We add the cell argument only for local_dimension() now and the
others when we find them useful.

I'd vote for 2 since we would only be guessing in attempting 1 before
we have a working prototype implementation.

-- 
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 15 Feb 2009 21:27:49 +0000

> we have a working prototype implementation.

This would help us.

Another useful function to add would be

     max_local_dimension

so that an assembler knows how much scratch space to allocate for assembly.

Garth

---

From: Anders Logg <[email-masked]>
Date: Sun, 15 Feb 2009 23:18:32 +0100

> so that an assembler knows how much scratch space to allocate for assembly.

Yes, that would also be useful.

-- 
Anders