dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature