Subject: [UFC-dev] Adding vectorized version of finite_element::evaluate_basis?

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 6 Feb 2008 11:53:45 +0100

I propose this addition to ufc::finite_element (the pure virtual
functions are existing versions).

    /// Evaluate basis function i at given point in cell
    virtual void evaluate_basis(unsigned int i,
                                double* values,
                                const double* coordinates,
                                const cell& c) const = 0;

    /// Evaluate all basis functions at given point in cell
    virtual void evaluate_basis(double* values,
                                const double* coordinates,
                                const cell& c) const
    { throw std::runtime_error("Not implemented (introduced in UFC v1.1)."); }

    /// Evaluate order n derivatives of basis function i at given point in cell
    virtual void evaluate_basis_derivatives(unsigned int i,
                                            unsigned int n,
                                            double* values,
                                            const double* coordinates,
                                            const ufc::cell& c) const = 0;

    /// Evaluate order n derivatives of all basis functions at given
point in cell
    virtual void evaluate_basis_derivatives(unsigned int n,
                                            double* values,
                                            const double* coordinates,
                                            const ufc::cell& c) const
    { throw std::runtime_error("Not implemented (introduced in UFC v1.1)."); }

The idea is the same as with evaluate_dofs, both reducing the number
of virtual function calls and exploiting that evaluation of all basis
functions can often be computed much more efficiently than one at a
time.

We said last month that Friday 8th was to be the deadline for further
changes to UFC 1.1, does anyone need more time?

--
Martin

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 6 Feb 2008 11:57:17 +0100

> changes to UFC 1.1, does anyone need more time?

A problem with using the same name is that it doesn't fit into the
current code generation format strings in the UFC utilities. Any
suggestions for plural names for evaluate_basis and
evaluate_basis_derivatives?

If we didn't care about backwards compatibility, we could rename the
old versions to evaluate_basis_function and
evaluate_basis_function_derivatives (growing long though...). But we
do care about that.

-- 
Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 06 Feb 2008 12:59:45 +0100

> evaluate_basis_derivatives?

how about 'evaluate_all_....'

then in ufc/finite_element.py:

  {
%(evaluate_basis)s
  }

  {
%(evaluate_all_basis)s
  }

etc.

would that work?

Kristian

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

---

From: Anders Logg <[email-masked]>
Date: Tue, 12 Feb 2008 18:03:46 +0100

> evaluate_basis_function_derivatives (growing long though...). But we

Even if we didn't need to be backwards compatible, it would still be a
problem to find the plural for evaluate_basis_function_derivatives:

  evaluate_basis_functions_derivatives
                         ~
Not very nice either.

I suggest we just add a suffix _all (similar to what Kristian suggested):

  evaluate_basis_all
  evaluate_basis_derivatives_all

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 13 Feb 2008 10:40:02 +0100

>   evaluate_basis_derivatives_all

Done. Feel free to proofread the documentation and header now.

Also, somebody should add code generation stubs to FFC and test
that the python utility code template compiles for you too.

-- 
Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 13 Feb 2008 12:45:08 +0100

> that the python utility code template compiles for you too.

I have this up and running now in FFC though I didn't commit it yet.
A simple question that might have an obvious answer:
Why do we have both evaluate_basis() and evaluate_basis_all() in the header
file? couldn't we just have evaluate_basis() and let the arguments determine
which function should be called? (evaluate_basis_all() does not take the integer
'i' specifying the basis function) For the code generation purposes we do need
the distinction, but that's all internal in FFC.

Kristian

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Feb 2008 12:45:43 +0100

> that the python utility code template compiles for you too.

ok, good. I hope to be able to do this tomorrow.

If there are no further objections, let's release 1.1 on Friday.

-- 
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Feb 2008 12:46:33 +0100

> ok, good. I hope to be able to do this tomorrow.

Didn't see that Kristian already had this covered.

-- 
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Feb 2008 12:47:43 +0100

> the distinction, but that's all internal in FFC.

I think we wanted to avoid overloading by name, to keep the interface
simple (?) and to make the code generation utilities (the dictionaries
provided by UFC) work.

-- 
Anders

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 13 Feb 2008 13:02:21 +0100

> simple (?) and to make the code generation utilities (the dictionaries

Yes, it was mainly for convenience. And in many situations (f.ex.
documentation) it's good to be able to refer to a function without
specifying the argument list. Also, if the interface is to be mirrored
in another language, it is best to avoid overloading by argument type.
Langtangen has previously shown interest in porting ufc to fortran.

--
Martin

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 13 Feb 2008 13:15:45 +0100

Quoting Martin Sandve Alnæs <[email-masked]>:

> > > > > > >     { throw std::runtime_error("Not implemented (introduced in
> UFC
> > > > v1.1)."); }
> > > > > > >
> > > > > > >     /// Evaluate order n derivatives of basis function i at given
> point
> > > > in cell
> > > > > > >                                             const ufc::cell& c)
> const =
> > > > 0;
> > > > > > >                                             const ufc::cell& c)
> const
> > > > > > >     { throw std::runtime_error("Not implemented (introduced in
> UFC
> > > > v1.1)."); }
> > > > > > >
> > > > > > >

The keys in the UFC dictionary should have the '_all' suffix, but the function
names does not necessarily have to.

> Langtangen has previously shown interest in porting ufc to fortran.

OK, it was just a question for consideration. When explicitly calling a function
by name, the chance of making a 'conscious' choice is also higher ;)

In FFC I currently throw a runtime error, so should I just update the references
and push to repo?

Kristian

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 13 Feb 2008 13:25:45 +0100

> names does not necessarily have to.

Right, I didn't think of that.

> by name, the chance of making a 'conscious' choice is also higher ;)

Yes. It's clearer that way.

> In FFC I currently throw a runtime error, so should I just update the references

It should be fine, users with an old UFC installation just won't get
this code generated, since
  "%(foo)s" % {"foo":"a", "bar":"b"}
is valid.

-- 
Martin