dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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.

> > 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).
> >
> > --
> > Anders
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>