dolfin team mailing list archive

[Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx>]

On 27 April 2011 12:38, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> On 27/04/11 11:08, Kristian Ølgaard wrote:
>> On 27 April 2011 11:52, Anders Logg <logg@xxxxxxxxx> 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
>>>> broken. I guess we need the form compiler to decide on the cell and
>>>> 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?
>>
>> 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.
>>
>
> 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.

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

> 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
>
>> Kristian
>>
>>> --
>>> Anders
>>>
>>>
>>>> Garth
>>>>
>>>> On 26/04/11 07:32, noreply@xxxxxxxxxxxxx wrote:
>>>>> ------------------------------------------------------------
>>>>> revno: 1014
>>>>> committer: Martin Alnæs <martinal@xxxxxxxxx>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dolfin
>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~ufl
>>> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ufl
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>
>