On Wed, Nov 18, 2009 at 09:11:04PM +0100, Johan Hake wrote: > On Wednesday 18 November 2009 12:14:04 Garth N. Wells wrote: > > Anders Logg wrote: > > > I've done some experimental work on figuring out a proper quadrature > > > element from a given C++ expression in the Python Expression class (in > > > expression.py). > > > > > > UFL and FFC now handle quadrature elements with unspecified degree, > > > although we may need to fine-tune how the degree is selected by FFC. > > > > > > There are two main obstacles to getting this working: > > > > > > 1. Understanding all the magic in expression.py. For example, what > > > does __new__ on line 533 do. It gets an element argument or extracts > > > it from the function space, but I don't see that it's being used. > > For the present version of expression.py line 533 points to a docstring.
I meant what does the function __new__ starting on line 532 do? It extracts an element but does nothing with the element. -- Anders > > > 2. Figuring out the correct shape for the quadrature element. This is > > > impossible to extract from the C++ expression string, so we either > > > need to specify a mesh argument to the constructor of Expression: > > > > > > f = Expression("sin(x[0])", mesh) > > > > > > or perhaps leave the domain shape undefined in UFL. This might break a > > > whole range of things in UFL for operations that depend on the shape, > > > like the gradient. > > > > > > On the other hand, that may be good since quadrature elements can't be > > > differentiated anyway. That way, UFL can give a sensible error message > > > when the form is defined: "Unable to do this operation since it is not > > > supported for quadrature functions." > > > > Sounds good. We may get into trouble when the assembler performs some > > checks on the dimension, etc of the coefficient functions. > > > > Or we can let UFL associate a cell shape based on other arguments in the > > form. > > > > > I can take a look at (2) but I really need help with (1). Hake? > > > > I'm building an understanding of how it works. > > > > It would be nice (and I think possible) to simplify expression.py. For > > example, in using std::vector<double>& in place of double* on the C++ > > side, a number of complicated dimension checks in expression.py can be > > removed. > > Good! It's nice to have more eyes on that code! > > The checks are there to prevent the nasty segfaults that occasionally occur > when using the eval from Python. But pushing theses test to a typemap, would > of course make things easier. > > Johan > > > Garth > > > > > The repository is here now: > > > > > > http://bitbucket.org/dolfin/dolfin/ > > > > > > Btw, Garth and I have discussed the possibility of moving the > > > repositories from fenics.org to Bitbucket. Less to maintain and we > > > don't need to rely on the good will of someones IT support (which may > > > not be indefinite). > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DOLFIN-dev mailing list > > > DOLFIN-dev@fenics.org > > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > _______________________________________________ > > DOLFIN-dev mailing list > > DOLFIN-dev@fenics.org > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > _______________________________________________ > DOLFIN-dev mailing list > DOLFIN-dev@fenics.org > http://www.fenics.org/mailman/listinfo/dolfin-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev