← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Attempt at simple fix for complex else{} case in Function::restrict.

 



Anders Logg wrote:
On Sat, Oct 03, 2009 at 10:12:45AM +0200, DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.

changeset:   7240:0db9cf9618e8
tag:         tip
user:        Anders Logg <logg@xxxxxxxxx>
date:        Sat Oct 03 10:12:40 2009 +0200
files:       dolfin/function/Coefficient.h dolfin/function/Data.h dolfin/function/Expression.cpp dolfin/function/Expression.h dolfin/function/Function.cpp dolfin/function/Function.h
description:
Attempt at simple fix for complex else{} case in Function::restrict.

Take a look and see if this makes sense:

1. The else{} case in restrict (the cell possibly being from another
mesh or another local function space) is now handled by a callback
through eval() through evaluate_dof, same as for Expression class.

2. Expression and Function both handle this through the common
restrict_as_ufc_function now placed in the Coefficient base class.

3. The inheritance of ufc::function has now been moved to the
Coefficient base class from Expression so both Expression and Function
now implement the ufc::function interface.

4. For various reasons, we have moved more stuff into the common
Coefficient base class than orginally intended, so it is no longer an
abstract base class for coefficients in forms (things that can be
restricted). So the question is if the current design makes sense.
Would it help to rename one or more of the classes, like having
GenericFunction and then Function and Expression? Does that make more
sense?


Yes.

Garth

--
Anders


------------------------------------------------------------------------

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev



References