← Back to team overview

dolfin team mailing list archive

Re: Dealing with incomplete UFL finite elements

 

On 27 April 2011 21:34, Anders Logg <logg@xxxxxxxxx> wrote:

> On Wed, Apr 27, 2011 at 09:30:08PM +0200, Martin Sandve Alnæs wrote:
> > 2011/4/27 Johan Hake <johan.hake@xxxxxxxxx>
> >
> >     On Wednesday April 27 2011 12:03:56 Martin Sandve Aln s wrote:
> >     > On 27 April 2011 19:07, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >     > > I'm starting here a new thread on how to deal with the recent
> change in
> >     > > UFL that has broken a good number of DOLFIN demos. The previous
> thread
> >     > > meandered and got side-tracked.
> >     > >
> >     > > The framework in we need to operate is:
> >     > >
> >     > > A. UFL will not allow forms to be modified post-construction.
> >     > >
> >     > > B. It should be relatively easy to replace ufl.Coefficients in a
> form
> >     > > and return a new form.
> >     > >
> >     > > C. The issue with replacing ufl.Coefficients is that we lose
> DOLFIN
> >     data
> >     > > (like the eval() functions) associated with the removed
> coefficients.
> >     > >
> >     > >
> >     > > I'll kick off with the obvious solution:
> >     > >
> >     > > 1. Require that all DOLFIN Expressions are associated with a
> >     > > ufl.FiniteElement.
> >     > >
> >     > > Other solutions?
> >     > >
> >     > > Garth
> >     >
> >     > 2.  At the stage when ffc calls ufl.preprocess, or even in
> >     ufl.preprocess,
> >     > let the preprocessed form contain ufl Coefficients with new
> elements in
> >     > place of the dolfin.Expressions. This is similar to the
> replacements done
> >     > for renumbering of Coefficients, and could either be done
> simultaneously
> >     or
> >     > as an additional step. The original Form and Expression objects
> will be
> >     > untouched, and the preprocessed form will be fine.
> >
> >     +
> >
> >     However, setting cell and degree is done during analysis and relies
> on
> >     form_data. The form is also preprocessed when the form_data is
> extracted.
> >     This
> >     means that for the preprocessed form to get correct signature, cell
> and
> >     degrees being set, we need to break up the logic.
> >
> >      1) extract form_data
> >      2) set degree and cell
> >      3) genererate preprocessed form
> >
> >
> > Lets figure out the exact algorithm if we need it. It could perhaps be
> > integrated better with preprocess. Or it might be better to extract just
> the
> > information needed to determine degree and cell first, and pass the
> element
> > replacements to preprocess.
>
> That's what I suggested in an earlier mail. Preprocess already gets
> common_cell. We could also figure out common_degree before calling
> preprocess but that requires getting the data stored in
> form_data.sub_elements.
>

Extracting all sub elements from a form before preprocessing should be easy
and efficient.

I assume it's still possible to construct an Expression with a specific
FunctionSpace? It is possible to write forms that will require that even
with the above solution.

Martin

Follow ups

References