dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Wednesday April 27 2011 12:45:46 Martin Sandve Alnæs wrote:
> 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? 

Yes.

Johan

> It is possible to write forms that will require that even
> with the above solution.
> 
> Martin