Subject: Re: [Ufl] [Branch ~ufl-core/ufl/main] Rev 1014: Add warnings to set_foo functions in finiteelement.py,

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 27 Apr 2011 10:40:50 +0100

We need a quick discussion round to resolve this issue - DOLFIN is now
broken. I guess we need the form compiler to decide on the cell and
element type, and then have UFL return a new form.

Garth

On 26/04/11 07:32, [email-masked] wrote:
> ------------------------------------------------------------
> revno: 1014
> committer: Martin Alnæs <[email-masked]>
> branch nick: ufl
> timestamp: Fri 2011-04-15 21:44:37 +0200
> message:
>   Add warnings to set_foo functions in finiteelement.py,
>   and remove repr modifications after construction time.
>   
>   If this will break your code, it likely wasn't working
>   correctly anyway and you need to rewrite it before you
>   can update to this UFL version.
>   
>   The set_foo functions will be removed completely before UFL 1.0.
>   
>   Happy easter holiday :)
> modified:
>   ufl/finiteelement.py
> 
> 
> --
> lp:ufl
> https://code.launchpad.net/~ufl-core/ufl/main
> 
> Your team UFL Core Team is subscribed to branch lp:ufl.
> To unsubscribe from this branch go to https://code.launchpad.net/~ufl-core/ufl/main/+edit-subscription

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Apr 2011 11:52:46 +0200

> element type, and then have UFL return a new form.

Yes, Martin mentioned at some point that it would be easy to add such
a function to UFL (that takes a form and replacement elements and
returns a new form).

Martin, could you add such a function?

--
Anders

> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

---

From: Kristian Ølgaard <[email-masked]>
Date: Wed, 27 Apr 2011 12:08:15 +0200

> Martin, could you add such a function?

I think ufl.algorithm.transformations.replace would work if
FiniteElementBase derived from 'Terminal'.
Currently, it derives from 'object', what is the reason for that?
Anyway, it should be simple enough to add something equivalent for elements.

Kristian

> Mailing list: https://launchpad.net/~ufl
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ufl

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 27 Apr 2011 11:38:11 +0100

> Anyway, it should be simple enough to add something equivalent for elements.

I was thinking that we only need to replace Coefficients, e.g. if a
Coefficient is defined using an 'incomplete element', FFC can create an
element, a Coefficient and the perform the replacement. Looks like UFL
can do this already.

The problem from the DOLFIN side is that the new UFL Coefficient will be
different from the DOLFIN/UFL Coefficient, and would be a
ufl.Coefficient and not a dolfin.Coefficient.

Garth

---

From: Kristian Ølgaard <[email-masked]>
Date: Wed, 27 Apr 2011 13:00:16 +0200

> element, a Coefficient and the perform the replacement. Looks like UFL

Yes, I think that should be possible. But what about quadrature elements?

If the scheme is not specified when constructing the element (in the
form), then the scheme
will be determined by the commandline arguments (or metadata) to FFC. The
QuadratureElement needs the scheme information in the constructor in order to
generate the points for which it is defined.

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 27 Apr 2011 12:03:13 +0100

> generate the points for which it is defined.

I don't see the problem. Couldn't FFC generate a new QuadratureElement
(of the correct degree) and define a Coefficient on it?

Garth

---

From: Kristian Ølgaard <[email-masked]>
Date: Wed, 27 Apr 2011 13:38:43 +0200

> (of the correct degree) and define a Coefficient on it?

I guess it could.

Another question is if we should have a separate class in UFL for
quadrature elements?
The reason is that UFL uses (family, cell, degree) to check for
uniqueness (through __repr__ --> __hash__),
but the quadrature element will need the 'scheme' as well, which can
be None until FFC determines it.

Either we extend the __repr__ of FiniteElement to include the scheme,
or we can use a separate class QuadratureElement.
For the majority of finite elements the 'scheme' information in
__repr__ is superfluous, so a separate class might be preferable.
If we use a separate class, then the question is if we want to do:

1) element = QuadratureElement(cell, degree, scheme)
or
2) element = FiniteElement(family, cell, degree, scheme=scheme)

when creating a quadrature element object.

For case 2 we probably need to implement FiniteElement.__new__ to
return a QuadratureElement if family == 'Quadrature'.

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:22:03 +0200

> Currently, it derives from 'object', what is the reason for that?

A terminal is an expression. A finite element is not an expression.

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:24:05 +0200

> >> Martin, could you add such a function?

I started some time before easter, but as Garth says...

> ufl.Coefficient and not a dolfin.Coefficient.

... this may be a problem. Since I don't really know the motivation for this
feature request, I can't solve this problem for you.

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:27:40 +0200

> > (of the correct degree) and define a Coefficient on it?

That would be natural to do simultaneously with replacing elements in other
coefficients.

> be None until FFC determines it.

Just set it to None by default.

> Either we extend the __repr__ of FiniteElement to include the scheme,

No problem.

That would require adding VectorQuadratureElement etc, and the same in
PyDolfin, major waste of time if you ask me.

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:33:14 +0200

Decide the cell as well? Some expressions are undefined with the cell
missing, because they need the spatial dimension to determine their shape...
I don't recall at the moment which ones, but at least grad(u) is undefined
if u doesn't have a cell. A likely result when the cell is undefined is
exceptions thrown with certain corner case forms.

Martin

On 27 April 2011 11:40, Garth N. Wells <[email-masked]> wrote:

> > To unsubscribe from this branch go to
> https://code.launchpad.net/~ufl-core/ufl/main/+edit-subscription
>
>

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Apr 2011 15:34:31 +0200

On Wed, Apr 27, 2011 at 03:24:05PM +0200, Martin Sandve Alnæs wrote:
>     On 27/04/11 11:08, Kristian  lgaard wrote:

The motivation is that we want to accomplish what we now accomplish
with the set_cell/degree functions that you have decided to remove.

This allows us to write f = Expression("sin(x[0])") and let the form
compiler choose a suitable approximation for the expression.

--
Anders

>     >>>> committer: Martin Aln s <[email-masked]>
>     >>>> branch nick: ufl

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 27 Apr 2011 14:39:17 +0100

> compiler choose a suitable approximation for the expression.

Just to keep the caching discussion alive ;), perhaps a DOLFIN
Expression (which is a subclass of ufl.Coefficient) with an incomplete
function space could have a cache ufl.Expressions that have completely
defined elements, but which share the eval() function of the original. I
don't know on a technical level how to make this work.

The JIT compiler would need to return a map of replaced -> new coefficients.

Garth

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Apr 2011 15:49:46 +0200

> The JIT compiler would need to return a map of replaced -> new coefficients.

I don't really understand why the set_degree/cell functions are so
bad. I understand that a form should be immutable, but if the cell and
degree are set to "?", we're not really changing anything.

Perhaps it would be enough to insert a check in the set_cell/degree
functions that they can only be called on objects where the cell/degree
has not been set?

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:50:44 +0200

> compiler choose a suitable approximation for the expression.

I'm fairly pessimistic... Let me look into it and come back later.

I spent quite a lot of time trying to get rid of (which failed) and
then minimize the requirement that an expr has a cell.
That problem may still work out ok for now, since
grad(Expression("sin(x[0]")) wouldn't work anyway.

Martin

---

From: Kristian Ølgaard <[email-masked]>
Date: Wed, 27 Apr 2011 15:53:55 +0200

> That would be natural to do simultaneously with replacing elements in other

Yes, we can start writing the code for this in ffc.analysis, but I
think that we will end up with something that might just as well
become a 'replace_element' function in ufl.algorithms.transformations

> Just set it to None by default.

Sure, since the scheme will be part of the __repr__, I'll add the
scheme argument between the degree and form_degree argument in
FiniteElement:

def __init__(self, family, cell, degree=None, quad_scheme=Nonw,
form_degree=None)

>> Either we extend the __repr__ of FiniteElement to include the scheme,

OK, that is my preferred solution. Just wanted to check if anyone had
a problem with the signature increase, or if there were some design
reasons to avoid this.

> PyDolfin, major waste of time if you ask me.

Yes I agree, but necessary if someone objects to extending __repr__.

Kristian

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 15:57:13 +0200

On 27 April 2011 15:49, Anders Logg <[email-masked]> wrote:

> > >>     > Anyway, it should be simple enough to add something equivalent
> for
> > >>     elements.
> > >>     >
> > >>

1) You don't know who else may have references to those objects. All bets
are off.

2) You change the hash of the objects. That messes up dicts and sets that
have them as keys. Severly.

3) The hack to update the repr of the objects isn't working, because
expressions that reference them may have their own cached repr strings which
won't get updated. Even if that wasn't a problem, dicts and sets would be
messed up by the changed hashes anyway.

> functions that they can only be called on objects where the cell/degree

Wouldn't change any of the above reasons.

Martin

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Apr 2011 16:00:15 +0200

On Wed, Apr 27, 2011 at 03:57:13PM +0200, Martin Sandve Alnæs wrote:
>     > > On Wed, Apr 27, 2011 at 03:24:05PM +0200, Martin Sandve Aln s wrote:
> 1) You don't know who else may have references to those objects. All bets are
> off.
>
> 2) You change the hash of the objects. That messes up dicts and sets that have
> them as keys. Severly.
>

I see your points but this has worked fine for a year or so. It's an
important feature so it's essential we find an alternative way to
handle unspecified elements.

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 16:00:47 +0200

On 27 April 2011 15:53, Kristian Ølgaard <[email-masked]> wrote:

> >> >>>>>> We need a quick discussion round to resolve this issue - DOLFIN
> is
> >> >>>>>> now

The replace_elements algorithm will be easy to add to ufl,
the problem is what to do with PyDOLFIN Functions and Expressions.

Martin

> >> >>> The problem from the DOLFIN side is that the new UFL Coefficient
> will
> >> >>> be

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 16:02:35 +0200

On 27 April 2011 16:00, Anders Logg <[email-masked]> wrote:

> >     > >>     >>> broken. I guess we need the form compiler to decide on
> the
> >     cell and
> >     > >>     >> Yes, Martin mentioned at some point that it would be easy
> to
> >     add such
> >     > >>     >> a function to UFL (that takes a form and replacement
> elements
> >     and
> >     > >>     >> returns a new form).
> >     > >>     >>
> >     > >>     > Currently, it derives from 'object', what is the reason
> for
> >     that?
> >     > >>     I was thinking that we only need to replace Coefficients,
> e.g. if
> >     a
> >     > >>     Coefficient is defined using an 'incomplete element', FFC
> can
> >     create an
> >     > >>     element, a Coefficient and the perform the replacement.
> Looks like
> >     UFL
> >     > >>     can do this already.
> >     > >>
> >     will be
> >     > >> ... this may be a problem. Since I don't really know the
> motivation
> >     for this
> are

I don't believe that it has actually worked without significant bugs as side
effects.
You've probably had lots of luck or subtle cache related bugs for a year or
so.

Martin

---

From: Johan Hake <[email-masked]>
Date: Wed, 27 Apr 2011 07:43:32 -0700

When is the element/cell set for a coefficient? If it is during code generation we can add that process to preprocess or what ne it now has, and the changes will only apply to the preprocessed form. 

Johan

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 27 Apr 2011 15:48:42 +0100

On 27/04/11 15:43, Johan Hake wrote:
> When is the element/cell set for a coefficient? 

It's decided by the form compiler, which does the setting by calling the
UFL set_foo functions.

Garth

< If it is during code
> generation we can add that process to preprocess or what ne it now has,
> and the changes will only apply to the preprocessed form. 
> 
> Johan
> 
> 
> On Apr 27, 2011, at 7:00, Martin Sandve Alnæs <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> On 27 April 2011 15:53, Kristian Ølgaard
>> <<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     On 27 April 2011 15:27, Martin Sandve Alnæs
>>     <<mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     > On 27 April 2011 13:38, Kristian Ølgaard
>>     <<mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >>
>>     >> On 27 April 2011 13:03, Garth N. Wells
>>     <<mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>     >> >
>>     >> >
>>     >> >> On 27 April 2011 12:38, Garth N. Wells
>>     <<mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>     >> >>>
>>     >> >>>
>>     >> >>>> On 27 April 2011 11:52, Anders Logg
>>     <<mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>     >> >>>>>> We need a quick discussion round to resolve this issue -
>>     DOLFIN is
>>     >> >>>>>> now
>>     the cell and
>>     to add
>>     >> >>>>> such
>>     elements and
>>     for that?
>>     >> >>>> Anyway, it should be simple enough to add something
>>     equivalent for
>>     >> >>>> elements.
>>     >> >>>>
>>     >> >>>
>>     e.g. if a
>>     can create
>>     >> >>> an
>>     Looks like UFL
>>     >> >> will be determined by the commandline arguments (or
>>     metadata) to FFC.
>>     >> >> The
>>     >> >> QuadratureElement needs the scheme information in the
>>     constructor in
>>     >> >> order to
>>     >> >>> The problem from the DOLFIN side is that the new UFL
>>     Coefficient will
>>     >> >>> be
>>     >> >>>>>> On 26/04/11 07:32,
>>     <mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]> wrote:
>>     >> >>>>>>>
>>     >> >>>>>>> committer: Martin Alnæs
>>     <<mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>>
>>     >> >>>>>>> branch nick: ufl
>>     >> >>>>>> Mailing list:
>>     <https://launchpad.net/~dolfin>https://launchpad.net/~dolfin
>>     >> >>>>>> Post to     :
>>     <mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>
>>     >> >>>>>> Unsubscribe :
>>     <https://launchpad.net/~dolfin>https://launchpad.net/~dolfin
>>     >> >>>>>> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >> >>>>>
>>     >> >>>>> Mailing list:
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> >>>>> Post to     :
>>     <mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>
>>     >> >>>>> Unsubscribe :
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> >>>>> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >> >>>>>
>>     >> >>>
>>     >> >>>
>>     >> >
>>     >> >
>>     >>
>>     >> Mailing list:
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> Post to     :
>>     <mailto:[email-masked]>[email-masked]
>>     <mailto:[email-masked]>
>>     >> Unsubscribe :
>>     <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>>     >> More help   :
>>     <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
>>     >
>>     >
>>
>>
>> Mailing list: <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>> Post to     : <mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>
>> Unsubscribe : <https://launchpad.net/~ufl>https://launchpad.net/~ufl
>> More help   :
>> <https://help.launchpad.net/ListHelp>https://help.launchpad.net/ListHelp
> 
>

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Apr 2011 16:54:14 +0200

> > and the changes will only apply to the preprocessed form.

Good point. It's set in the analysis.py in FFC, right after the call
to preprocess (compute_form_data). It only relies on the

  form_data.cell
  form_data.sub_elements

So we might be able to handle it by making sure the preprocessed_form
gets as input the two arguments common_cell and common_degree that are
computed in the function _adjust_elements in analysis.py.

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 17:00:30 +0200

> It's decided by the form compiler, which does the setting by calling the

Does anyone outside the form compiler depend on the side effects of these
set_foo calls?

Will this modify f?
f = Expression("x[0]")
q = assemble(f*triangle.x[0]*dx)
That is, will it call set_foo on the original dolfin coefficients or the
replacement ufl coefficients made in preprocess?

Garth
> > and the changes will only apply to the preprocessed form.

That would make the scope of potential problems somewhat manageable.
In particular, there should be no side effects in user code.

Martin

---

From: Johan Hake <[email-masked]>
Date: Wed, 27 Apr 2011 08:07:39 -0700

On Wednesday April 27 2011 07:54:14 Anders Logg wrote:
> to preprocess (compute_form_data). 

Well, then I guess the form which get changed is already stripped from any 
DOLFIN specific objects :)

Are there other situations where we per today change the form in a now illegal 
way? Adaptivity comes in my mind...

Johan

> It only relies on the
> > >>     >> >>>>> On Wed, Apr 27, 2011 at 10:40:50AM +0100, Garth N. Wells
> > >>     
> > >>     wrote:
> > >>     >> >>>> I think ufl.algorithm.transformations.replace would work
> > >>     >> >>>> if FiniteElementBase derived from 'Terminal'.
> > >>     >> >> If the scheme is not specified when constructing the element
> > >>     
> > >>     (in the
> > >>     
> > >>     >> >> form), then the scheme
> > >>     >> > I don't see the problem. Couldn't FFC generate a new
> > >>     
> > >>     QuadratureElement
> > >>     
> > >>     > That would be natural to do simultaneously with replacing
> > >>     
> > >>     elements in other
> > >>     
> > >>     > coefficients.
> > >>     
> > >>     >> Another question is if we should have a separate class in UFL
> > >>     >> for quadrature elements?
> > >>     >> but the quadrature element will need the 'scheme' as well,
> > >>     
> > >>     which can
> > >>     
> > >>     >> Either we extend the __repr__ of FiniteElement to include the
> > >>     
> > >>     scheme,
> > >>     
> > >>     > No problem.
> > >>     
> > >>     OK, that is my preferred solution. Just wanted to check if anyone
> > >>     had a problem with the signature increase, or if there were some
> > >>     design reasons to avoid this.
> > >>     
> > >>     > That would require adding VectorQuadratureElement etc, and the
> > >>     
> > >>     same in
> > >>     
> > >>     >> __repr__ is superfluous, so a separate class might be
> > >>     >> preferable. If we use a separate class, then the question is
> > >>     >> if we want to do:
> > >>     >> 
> > >>     >> For case 2 we probably need to implement FiniteElement.__new__
> > >>     >> to return a QuadratureElement if family == 'Quadrature'.
> > >>     >> 
> > >>     >> Kristian
> > >>     >> 
> > >>     >> > Garth
> > >>     >> > 
> > >>     >> >> Kristian
> > >>     >> >> 
> > >>     >> >>>>>>>   Add warnings to set_foo functions in
> > >>     >> >>>>>>>   finiteelement.py, and remove repr modifications
> > >>     >> >>>>>>>   after construction time.
> > >>     >> >>>>>>>   
> > >>     >> >>>>>>>   If this will break your code, it likely wasn't
> > >>     >> >>>>>>>   working correctly anyway and you need to rewrite it
> > >>     >> >>>>>>>   before you can update to this UFL version.
> > >>     >> >>>>>>>   
> > >>     >> >>>>>>>   The set_foo functions will be removed completely
> > >>     
> > >>     before UFL 1.0.
> > >>     
> > >>     >> >>>>>>>   Happy easter holiday :)
> > >>     >> >>>>>>> 
> > >>     >> >>>>>>> modified:
> > >>     >> >>>>>>>   ufl/finiteelement.py
> > >>     >> >>>>>>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 17:13:29 +0200

> DOLFIN specific objects :)

That could explain why it has worked. No side effects. Otherwise, just pure
luck...

Are there other situations where we per today change the form in a now
> illegal

There probably are, since somebody experienced caching bugs related to this.

And I have to arrest you on the "now illegal", this is nothing new... :)

Martin

Johan
> > > >>     <https://help.launchpad.net/ListHelp>
> https://help.launchpad.net/Li
> > > >>     stHelp
> > > >>
> > > >>     <https://help.launchpad.net/ListHelp>
> https://help.launchpad.net/Li
> > > >>     stHelp
> > > >>
> > > >>     <https://help.launchpad.net/ListHelp>
> https://help.launchpad.net/Li
> > > >>     stHelp
> > > >>
> > > >> <https://help.launchpad.net/ListHelp>
> https://help.launchpad.net/ListHe
> > > >> lp
> > > >

---

From: Johan Hake <[email-masked]>
Date: Wed, 27 Apr 2011 08:18:13 -0700

On Wednesday April 27 2011 08:13:29 Martin Sandve Alnæs wrote:
> > > > It's decided by the form compiler, which does the setting by calling
> > 
> > the
> > 
> > > > UFL set_foo functions.
> > > > 
> > > > < If it is during code
> > > > 
> > > > > generation we can add that process to preprocess or what ne it now
> > 
> > has,
> > 
> > Well, then I guess the form which get changed is already stripped from
> > any DOLFIN specific objects :)
> 

:)

> There probably are, since somebody experienced caching bugs related to

That was me :)

> And I have to arrest you on the "now illegal", this is nothing new... :)

He, he, not sure if I actually mean this, but: it is good to have you back!

Johan

> > > > >>     <<mailto:[email-masked]>[email-masked]
> > > > >>     <mailto:[email-masked]>>
> > 
> > wrote:
> > > > >>     >> >>>>> On Wed, Apr 27, 2011 at 10:40:50AM +0100, Garth N.
> > 
> > Wells
> > 
> > > > >>     wrote:
> > > > >>     >> >>>>>> We need a quick discussion round to resolve this
> > > > >>     >> >>>>>> issue
> > 
> > -
> > 
> > > > >>     DOLFIN is
> > > > >>     
> > > > >>     >> >>>>>> now
> > > > >>     >> >>>>> Yes, Martin mentioned at some point that it would be
> > 
> > easy
> > 
> > > > >>     to add
> > > > >>     
> > > > >>     >> >>>>> such
> > > > >>     >> >>>> I think ufl.algorithm.transformations.replace would
> > > > >>     >> >>>> work if FiniteElementBase derived from 'Terminal'.
> > > > >>     >> >> If the scheme is not specified when constructing the
> > 
> > element
> > 
> > > > >>     (in the
> > > > >>     
> > > > >>     >> >> form), then the scheme
> > > > >>     Yes, we can start writing the code for this in ffc.analysis,
> > > > >>     but
> > 
> > I
> > 
> > > > >>     think that we will end up with something that might just as
> > > > >>     well become a 'replace_element' function in
> > > > >>     ufl.algorithms.transformations
> > > > >> 
> > > > >>     >> Another question is if we should have a separate class in
> > > > >>     >> UFL for quadrature elements?
> > > > >>     >> The reason is that UFL uses (family, cell, degree) to check
> > 
> > for
> > 
> > > > >>     Sure, since the scheme will be part of the __repr__, I'll add
> > 
> > the
> > 
> > > > >>     def __init__(self, family, cell, degree=None,
> > > > >>     quad_scheme=Nonw, form_degree=None)
> > > > >>     
> > > > >>     OK, that is my preferred solution. Just wanted to check if
> > 
> > anyone
> > 
> > > > >>     had a problem with the signature increase, or if there were
> > > > >>     some design reasons to avoid this.
> > > > >>     
> > > > >>     >> For the majority of finite elements the 'scheme'
> > > > >>     >> information
> > 
> > in
> > 
> > > > >>     >> preferable. If we use a separate class, then the question
> > > > >>     >> is if we want to do:
> > > > >>     >> 
> > > > >>     >> 2) element = FiniteElement(family, cell, degree,
> > 
> > scheme=scheme)
> > 
> > > > >>     >> For case 2 we probably need to implement
> > 
> > FiniteElement.__new__
> > 
> > > > >>     >> >>> different from the DOLFIN/UFL Coefficient, and would be
> > > > >>     >> >>> a ufl.Coefficient and not a dolfin.Coefficient.
> > > > >>     >> >>> 
> > > > >>     >> >>> Garth
> > > > >>     >> >>> 
> > > > >>     >> >>>> Kristian
> > > > >>     >> >>>> 
> > > > >>     >> >>>>>> Garth
> > > > >>     >> >>>>>> 
> > > > >>     >> >>>>>> On 26/04/11 07:32,
> > > > >>     
> > > > >>     >> >>>>>>>   working correctly anyway and you need to rewrite
> > > > >>     >> >>>>>>>   it before you can update to this UFL version.
> > > > >>     >> >>>>>>>   
> > > > >> Mailing list: <https://launchpad.net/~ufl>
> > 
> > https://launchpad.net/~ufl
> > 
> > > > >> Post to     : <mailto:[email-masked]>
> > 
> > [email-masked]
> > 
> > > > >> Unsubscribe : <https://launchpad.net/~ufl>
> > 
> > https://launchpad.net/~ufl
> > 
> > > > >> More help   :

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 27 Apr 2011 17:24:41 +0200

> > There probably are, since somebody experienced caching bugs related to

What did you do to provoke it? Adaptivity? Or just using Expression("...")?
I guess the cache bugs could occur while only using Expression, but that
will still require a replace_elements algorithm (perhaps built into
preprocess)
to work correctly.

> He, he, not sure if I actually mean this, but: it is good to have you back!

Well, eh, thanks? :-P
Not sure if I actually mean this, but: it's good to be back :)

Martin

Johan
> > > > > >>     >> >>>>>> broken. I guess we need the form compiler to
> decide
> > > > > >>     >> >>>>>> on
> > > > > >>
> > > > > >>     the cell and
> > > > > >>
> [email-masked]

---

From: Johan Hake <[email-masked]>
Date: Wed, 27 Apr 2011 08:47:31 -0700

On Wednesday April 27 2011 08:24:41 Martin Sandve Alnæs wrote:
> > > > > > It's decided by the form compiler, which does the setting by
> > 
> > calling
> > 
> > > > the
> > > > 
> > > > > > UFL set_foo functions.
> > > > > > 
> > > > > > < If it is during code
> > > > > > 
> > > > > > > generation we can add that process to preprocess or what ne it
> > 
> > now
> > 
> > > > has,
> > > > 
> > > > > Good point. It's set in the analysis.py in FFC, right after the
> > > > > call to preprocess (compute_form_data).
> > > > 
> > > > Well, then I guess the form which get changed is already stripped
> > > > from any DOLFIN specific objects :)
> > > 
> > > That could explain why it has worked. No side effects. Otherwise, just
> > 
> > pure
> > 
> > > luck...
> > :
> > :)
> > :

No fancy stuff, just pretty large forms involving a bunch of R spaces. I have 
intended to debug this, as I lately have been able to reproduce the bug with 
much smaller forms. My other forms created a signature of some 300K 
characters...

> Not sure if I actually mean this, but: it's good to be back :)

:D

Johan

> Martin
> 
> Johan
> 
> > > Martin
> > > 
> > > 
> > > Johan
> > > 
> > > > > It only relies on the
> > > > > 
> > > > >   form_data.cell
> > > > >   form_data.sub_elements
> > > > > 
> > > > > So we might be able to handle it by making sure the
> > > > > preprocessed_form gets as input the two arguments common_cell and
> > > > > common_degree that
> > 
> > are
> > 
> > > > > > > On Apr 27, 2011, at 7:00, Martin Sandve Alnæs <
> > 
> > [email-masked]
> > 
> > > > > > >>     >> >>>>> Yes, Martin mentioned at some point that it would
> > 
> > be
> > 
> > > > easy
> > > > 
> > > > > > >>     to add
> > > > > > >>     
> > > > > > >>     >> >>>>> such
> > > > > > >>     >> >>>>> a function to UFL (that takes a form and
> > 
> > replacement
> > 
> > > > > > >>     elements and
> > > > > > >>     
> > > > > > >>     >> >>>>> returns a new form).
> > > > > > >>     >> >>>>> 
> > > > > > >>     >> >>>> I think ufl.algorithm.transformations.replace
> > > > > > >>     >> >>>> would work if FiniteElementBase derived from
> > > > > > >>     >> >>>> 'Terminal'. Currently, it derives from 'object',
> > > > > > >>     >> >>>> what is the reason
> > > > > > >>     
> > > > > > >>     for that?
> > > > > > >>     
> > > > > > >>     >> >>> element, a Coefficient and the perform the
> > 
> > replacement.
> > 
> > > > > > >>     Looks like UFL
> > > > > > >>     
> > > > > > >>     >> >>> can do this already.
> > > > > > >>     >> >> 
> > > > > > >>     Yes, we can start writing the code for this in
> > > > > > >>     ffc.analysis, but
> > > > 
> > > > I
> > > > 
> > > > > > >>     think that we will end up with something that might just
> > > > > > >>     as well become a 'replace_element' function in
> > > > > > >> the problem is what to do with PyDOLFIN Functions and
> > 
> > Expressions.
> > 
> > > > > > >> Martin
> > > > > > >> 
> > > > > > >>     >> Another question is if we should have a separate class
> > > > > > >>     >> in UFL for quadrature elements?
> > > > > > >>     >> The reason is that UFL uses (family, cell, degree) to
> > 
> > check
> > 
> > > > for
> > > > 
> > > > > > >>     >> but the quadrature element will need the 'scheme' as
> > 
> > well,
> > 
> > > > > > >>     which can
> > > > > > >>     
> > > > > > >>     Sure, since the scheme will be part of the __repr__, I'll
> > 
> > add
> > 
> > > > the
> > > > 
> > > > > > >>     scheme argument between the degree and form_degree
> > > > > > >>     argument
> > 
> > in
> > 
> > > > > > >>     FiniteElement:
> > > > > > >>     
> > > > > > >>     had a problem with the signature increase, or if there
> > > > > > >>     were some design reasons to avoid this.
> > > > > > >>     
> > > > > > >>     >> preferable. If we use a separate class, then the
> > > > > > >>     >> question is if we want to do:
> > > > > > >>     >> 
> > > > > > >>     >> >>> different from the DOLFIN/UFL Coefficient, and
> > > > > > >>     >> >>> would
> > 
> > be
> > 
> > > > > > >>     >> >>>>>>>   finiteelement.py, and remove repr
> > > > > > >>     >> >>>>>>>   modifications after construction time.
> > > > > > >>     >> >>>>>>>   
> > > > > > >>     >> >>>>>>>   If this will break your code, it likely
> > > > > > >>     >> >>>>>>>   wasn't working correctly anyway and you need
> > > > > > >>     >> >>>>>>>   to
> > 
> > rewrite
> > 
> > > > > > >>     >> >>>>>>>   The set_foo functions will be removed
> > 
> > completely
> > 
> > > > > > >>     before UFL 1.0.
> > > > > > >>     
> > > > > > >>     >> >>>>>>>   Happy easter holiday :)
> > > > > > >>     >> >>>>>>> 
> > > > > > >>     >> >>>>>>> modified:
> > > > > > >>     >> >>>>>>>   ufl/finiteelement.py
> > > > > > >>     >> >>>>>> 
> > > > > > >>     <https://launchpad.net/~dolfin>
> > 
> > https://launchpad.net/~dolfin
> > 
> > > > > > >>     >> >>>>>> Post to     :
> > > > > > >>     <https://launchpad.net/~dolfin>
> > 
> > https://launchpad.net/~dolfin
> > 
> > > > > > >>     >> >>>>>> More help   :