Subject: [UFC-dev] dof_map::local_dimension(ufc::cell& c)

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 28 Apr 2009 11:26:48 +0100

If I go ahead and add

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

to UFC, is there a preference to retain dof_map::local_dimension() or to 
remove it?

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 1 May 2009 17:47:28 +0200

The problem with removing it is that it breaks compatibility both ways.
Previously we have tried to keep the interface compilable with old code
and new code compilable with the old interface, in particular since it
eases the transition.

Martin

On Tue, Apr 28, 2009 at 12:26 PM, Garth N. Wells <[email-masked]> wrote:
> _______________________________________________
> UFC-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufc-dev
>

---

From: "Garth N. Wells" <[email-masked]>
Date: Sun, 03 May 2009 20:43:06 +0100

> and new code compilable with the old interface, in particular since it

Sure, although I removed dof_map::local_dimension() in the end since 
assemblers should only use dof_map::local_dimension(ufc:cell&) and I 
think that it's better to keep UFC clean rather than backwards 
compatible while the number of users is limited (so far just FFC and 
SyFi(?), and I did the update for FFC). This may well change of course.

On the side, I'm very pleased with the change. We're using 
dolfin::Assembler(...) and a few other key DOLFIN classes which we 
couldn't use before for a particular application with a variable number 
of dofs per node/cell.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 4 May 2009 10:16:44 +0200

On Sun, May 3, 2009 at 9:43 PM, Garth N. Wells <[email-masked]> wrote:
> assemblers should only use dof_map::local_dimension(ufc:cell&) and I think
> that it's better to keep UFC clean rather than backwards compatible while
> the number of users is limited (so far just FFC and SyFi(?), and I did the
> update for FFC). This may well change of course.

The problem i only during the transition, since this change to DOLFIN
forces SFC to update to stay compatible, which can be problematic
while DOLFIN isn't stable.

A compatible solution would be simply for the new local_dimension(cell)
to call local_dimension(), renaming the template variable for the new
function to "local_dimension2".

Also, for efficiency it might not be desirable in all cases to use
local_dimension(cell), both because of the extra virtual function
call and perhaps more important because the assumption of a
fixed size may allow some optimizations.

Anyway, I'll just refrain from updating anything for a little while.

> dolfin::Assembler(...) and a few other key DOLFIN classes which we couldn't
> use before for a particular application with a variable number of dofs per
> node/cell.

Nice.

Martin

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 04 May 2009 11:28:50 +0100

> while DOLFIN isn't stable.

Isn't it the point to use the 'experimental ufc' in DOLFIN for volatile 
changes and 'stable' changes which are agreed upon are made to ufc.h?

> fixed size may allow some optimizations.

This doesn't prevent the use of local_dimension(cell). A dummy cell 
argument can be passed. The extra virtual function calls by the 
assembler may not be desirable, but it's the task of the assembler to 
figure this out. UFC could provide a function

     bool dof_map::const_local_dimension()

to help assemblers.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 4 May 2009 12:57:41 +0200

On Mon, May 4, 2009 at 12:28 PM, Garth N. Wells <[email-masked]> wrote:
>>> think

Yes, exactly. But this change was applied to ufc directly,
and doesn't preserve compatibility like previous versions.

But don't bother changing anything now, I'll just
refrain from updating anything for a while.

> This doesn't prevent the use of local_dimension(cell). A dummy cell argument
> can be passed. The extra virtual function calls by the assembler may not be
> desirable, but it's the task of the assembler to figure this out. UFC could
> provide a function
>

Ok. Then the assembler can also use max_local_dimension() to avoid
making a dummy cell.

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 4 May 2009 16:22:14 +0200

> and doesn't preserve compatibility like previous versions.

I guess the point here is that the addition of the cell argument to
local_dimension() has been agreed upon for some time now, so it's ok
to put them directly into UFC.

The problem though is that we need to make a new release of UFC next
time we release DOLFIN. If that takes a while, we might be able to add
other stuff we've talked about and release a new version, but
it would be good if we could avoid making many releases of UFC with
only minor changes.

-- 
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 04 May 2009 15:37:18 +0100

> it would be good if we could avoid making many releases of UFC with

There are quite a few suggestions for UFC v1.2 in the TODO file which 
won't break compatibility so perhaps it's a good time to decide which 
ones should be added and which should be dismissed (I think we already 
dismissed foo_integral::tabulate_tensors()). Then when the time comes 
for a release the changes will be more substantial. The big topic that I 
see on the horizon is non-affine elements which I doubt will be ready 
for a v1.2 release.

Garth

> 
> 
> ------------------------------------------------------------------------
>

---

From: Shawn Walker <[email-masked]>
Date: Mon, 4 May 2009 10:43:22 -0400 (EDT)

> see on the horizon is non-affine elements which I doubt will be ready

Correct.  Do not add that 'higher_order_coordinates' variable or any of 
the higher order mesh stuff to UFC.  There is still some trial and error.

- Shawn