Subject: [Fenics-ufc] Double pointers

From: Anders Logg <[email-masked]>
Date: Mon, 26 Sep 2011 14:04:30 +0200

On Wed, Sep 21, 2011 at 07:06:02PM +0200, Anders Logg wrote:
> On Wed, Sep 21, 2011 at 04:54:29PM -0000, Garth Wells wrote:
> > On 21 September 2011 17:40, Johan Hake <[email-masked]> wrote:
> > > On Wednesday September 21 2011 09:00:16 Garth Wells wrote:
> > >> We should look at this  - it will allow the removal of some ugly copies
> > >> in DOLFIN.
> > >
> > > Agree, but at the moment are boost::multi_arrays not so pleasent for the SWIG
> > > interface. Copying is enforced. Not sure this is a big deal for such a low
> > > lever functionality, but it is sad that it should be needed, if the underlying
> > > structure is just a c-array, which numpy wraps just fine.
> > >
> >
> > I think that if this type of data is used intensively at the Python
> > level, then there will be bigger performance issues to worry about
> > than data copying.
> >
> > The multi_array interface is somewhat secondary - the important point
> > is flattening the double pointer in the UFC interface.
>
> We should avoid using any other data structures than plain C arrays in
> the UFC interface.
>
> Or we should use STL data structures (or boost) throughout UFC, but
> that sounds more like UFC >= 3.0.

We should make a new UFC release to fix at least the bug in the
quadrature version of tabulate_tensor for interior_facet_integral.

Should we also change the double pointers into plain arrays?

This would mean quite subtstantial changes as the following variables
and arguments will need to change:

  cell::entity_indices
  cell::coordinates
  tabulate_tensor(..., w, ...)
  tabulate_tensor(..., quadrature_points, ...)

This will also require changes DOLFIN and FFC/SFC and (perhaps the
most time-consuming part...) in the UFC manual.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 26 Sep 2011 13:17:21 +0100

On 26 September 2011 13:12, Kent-Andre Mardal <[email-masked]> wrote:
>
>
> On 26 September 2011 14:04, Anders Logg <[email-masked]> wrote:
>>
> I don't think we should change this at this moment.
>

Reasoning?

Garth

> Kent
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : [email-masked]
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>
>

---

From: Kent-Andre Mardal <[email-masked]>
Date: Mon, 26 Sep 2011 14:12:20 +0200

Kent

---

From: Kent-Andre Mardal <[email-masked]>
Date: Mon, 26 Sep 2011 14:25:38 +0200

On 26 September 2011 14:17, Garth N. Wells <[email-masked]> wrote:

> >> > > > Agree, but at the moment are boost::multi_arrays not so pleasent
> for
> >> > > > the SWIG
> >> > > > interface. Copying is enforced. Not sure this is a big deal for
> such
> >> > > > a low
> >> > > > lever functionality, but it is sad that it should be needed, if
> the
> >> > > > underlying

It does not add anything and the book is just around the corner.
UFC needs a revision later anyway to make it more suited for e.g.
multi-domain
methods.

Kent

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 26 Sep 2011 15:57:00 +0200

Please don't. We have to focus on stabilizing FEniCS now, or there
will never be a stable 1.0.

Martin

On 26 September 2011 14:25, Kent-Andre Mardal <[email-masked]> wrote:
> Mailing list: https://launchpad.net/~fenics-ufc
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics-ufc

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 26 Sep 2011 15:13:05 +0100

> It does not add anything and the book is just around the corner.

It adds consistency to the interface and will remove some hacks on the
DOLFIN side.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 26 Sep 2011 16:30:30 +0200

> It adds consistency to the interface and will remove some hacks on the

It's a good idea for a future version, but it adds nothing for the
end-user, and it adds a lot of work all over the place, which is a
recipe for introducing new bugs, which is a horrible idea just before
a release.

Really, please don't.

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 26 Sep 2011 20:31:40 +0200

> recipe for introducing new bugs, which is a horrible idea just before

I agree. In particular, I'm not very keen on rewriting the UFC chapter
for the FEniCS book just now.

My suggestion is a quick fix of the copy-paste error in the
tabulate_tensor function for interior_facet_integral and then a
release of 2.0.2.

--
Anders