Johan Hake wrote:
> On Tuesday 29 September 2009 22:39:02 Anders Logg wrote:
>> On Tue, Sep 29, 2009 at 10:29:14PM +0200, Johan Hake wrote:
>>> On Tuesday 29 September 2009 22:10:54 Anders Logg wrote:
>>>> On Tue, Sep 29, 2009 at 08:55:03PM +0100, Garth N. Wells wrote:
>>>>> I'm looking forward to seeing the new code. Is all the old
>>>>> functionality still in place?
>>>> Yes and no. Everything except the generated CoefficientSet stuff
>>>> should still work in the C++ interface, but the Python interface won't
>>>> work until the corresponding changes have been made on the Python side.
>>>>
>>>> Here's some more information about the changes:
>>>>
>>>> 1. Subclassing Function and overloading eval() has been replaced by
>>>> the Expression subclass which works in the same way with eval().
>>>>
>>>> 2. All the old functionality/logic of the Function class is still in
>>>> place but it can now be cleaned up and simplified.
>>>>
>>>> 3. A Function will now *always* have a FunctionSpace and *always* have
>>>> a vector.
>>> Good!
>>>
>>>> 4. An Expression *never* has a FunctionSpace and *never* has a vector.
>>> Also good! Should we consider (re-)adding a value_rank and dimension
>>> method to the expression class?
>> Yes, perhaps. But it's very convenient not having to specify it. We
>> could make it optional.
>
> Ok. No big dealt for me. In Python we can solve this for Expressions anyway.
>
>>> Also what would the preferred solution be for a Python expression. It
>>> should not have a FunctionSpace but we need a FunctionSpace to initialize
>>> the ufl.Function. Or rather the ufl.FiniteElement that comes with the
>>> FunctionSpace.
>>>
>>> I see two alternatives:
>>> 1) Instantiate an Expression with a FunctionSpace, then let the
>>> FunctionSpace reside in the Python layer. The ufl.FiniteElement is used
>>> to instantiate the ufl.Function.
>>>
>>> 2) Instantiate an Expression with a ufl.FiniteElement. The problem with
>>> this is that we have not exposed the ufl.FiniteElement in the PyDOLFIN
>>> interface previously. But the confusion with an expression having a
>>> FunctionSpace is partly avoided.
>>>
>>> In both cases I could add checks for rank and dimensions in the Python
>>> layer if we decides to not require it for the C++ interface.
>> I think we discussed the possibility of detecting the value dimension
>> from the expression
>
> Yes, but a user can initialize an Expression with the wrong
> FunctionSpace/FiniteElement compared to what the expression looks like.
>
>> and automatically using piecewise linears if not
>> otherwise specified.
>>
>> The function space could be an optional argument:
>>
>> f = Expression("sin(x[0])", V=V)
>
> We cannot automatically figure out the topological dimension, can we?
>
We can from the function space.
> Should we require that an Expression is instantiated using just a
> ufl.FiniteElement? In this way it would be clear that the Expression is not
> defined in a FunctionSpace? It would then look like:
>
> f = Expression(V.ufl_element(),"sin(x[0])")
>
> or something.
>
Doesn't this defeat the purpose of having 'Expression' (i.e. no function
space)? Could we just pass the cell type?
Garth
>> Then it would be clear that f is not a function in V, but V is only
>> some additional information about how f should be used in forms.
>>
>>>> 5. FunctionSpaces are not attached to coefficients when doing a.f = f.
>>>>
>>>> 6. The DOLFIN wrappers have been simplified and now rely on the
>>>> new very simple CoefficientAssigner class.
>>>>
>>>> 7. The assembler works through the common base class Coefficient, in
>>>> particular the restrict() function for restricting to a local element.
>>> Nice!
>> This also removes one of the too many interpolate() functions which is
>> good.
>
> Ok.
>
> Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@fenics.org
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev
