ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxx>]

2010/1/6 Anders Logg <logg@xxxxxxxxx>:
> On Wed, Jan 06, 2010 at 11:24:04AM +0100, Kristian Oelgaard wrote:
> > 2010/1/6 Anders Logg <logg@xxxxxxxxx>:
> > >We've come pretty far on the rewrite of FFC and only a few functions
> > >remain. As far as I can see, it remains to implement code generation
> > >for the following functions:
> > >
> > >Kristian:
> > >
> > > code["evaluate_basis_all"] = not_implemented
> >
> > This should be easy to implement.
> > Would it be an idea to let evaluate_basis() call evaluate_basis_all() and then pick the correct value?
> > This will remove a lot of redundant code at the cost of some overhead introduced by the function call.
> > However, I don't see why one would call evaluate_basis() if evaluate_basis_all() works, I imagine that the assembler will call evaluate_basis_all() in the future for efficiency?
>
> I don't think the assembler calls evaluate_basis_all. It's only used
> in special cases for people that write their own assemblers (Nitsche
> on overlapping meshes, crack propagation, partition of unity etc).

I think I tracked a call from the assembler to evaluate_basis, but that was in a very old DOLFIN I guess. Now evaluate_basis() is just called from one of the Function::eval() functions.

> But having evaluate_basis call evaluate_basis_all sounds like it would
> result in very much overhead. It would evaluate all basis functions
> even if just one is needed. Wouldn't it be more natural to do the opposite?

But if users will use evaluate_basis_all() (if available) rather than evaluate_basis() it is better to call evaluate_basis from evaluate_basis_all than the other way around.
The fastest will be to just include all the code in both functions.
Getting the value of all basis functions is not that demanding once the values of the expansion polynomial basis are computed (which is the same for all basis functions). Then it is just a matrix vector multiply of the coefficients (tabulated) and the basis values (computed at run-time).

> > > code["evaluate_basis_derivatives"] = not_implemented
> > > code["evaluate_basis_derivatives_all"] = not_implemented
> > >
> > >Marie:
> > >
> > > code["tabulate_entity_dofs"] = not_implemented # Marie doesn't know what this function should do
> > > code["tabulate_coordinates"] = not_implemented # Marie doesn't believe in this function
> > >
> > >Marie or Kristian:
> > >
> > > code["interpolate_vertex_values"] = not_implemented
> > >
> > >In addition, we need to get the code generation for the integral
> > >classes working. It's sort of working for the tensor representation
> > >but not at all (?) for the quadrature representation. I'll be working
> > >on getting the tensor representation completely in place.
> >
> > I don't think the quadrature code for integrals work at all, but I haven't checked. If you set up the infrastructure for combining code from different integrals, I'll take care of the quadrature part.
>
> ok. I will look at it. But you can also experiment with just changing
> one line in codegeneration.py. Change from
>
>  code = generate_tensor_integrals(ir, options)
>
> to
>
>  code = generate_quadrature_integrals(ir, options)
>
> Note that in the new approach, all code needs to be generated as a
> string, not a list of declarations but maybe that was only used by the
> tensor representation before anyway.

OK

Kristian

> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktEbJQACgkQTuwUCDsYZdE6JwCePzSA6iEP1Pw9ODwYyN+wc+e7
> kukAoIem9SAzancyFMvKlJn//PWVWTdi
> =vZ7I
> -----END PGP SIGNATURE-----

Attachment: signature.asc
Description: OpenPGP digital signature