ffc team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> Johan Hoffman wrote:
>>> On Mon, Feb 05, 2007 at 10:28:07AM +0100, Johan Hoffman wrote:
>>>>> On Fri, Feb 02, 2007 at 10:15:09PM +0100, Garth N. Wells wrote:
>>>>>>
>>>>>> Anders Logg wrote:
>>>>>>> On Fri, Feb 02, 2007 at 09:32:13PM +0100, Garth N. Wells wrote:
>>>>>>>> Anders Logg wrote:
>>>>>>>>> On Fri, Feb 02, 2007 at 02:46:35PM +0100, Johan Hoffman wrote:
>>>>>>>>>>> Johan Hoffman wrote:
>>>>>>>>>>>> About the global dof numbering for the different components in
>>>> a
>>>>>>>>>>>> function
>>>>>>>>>>>> defined by a mixed element: I get the impression that we use a
>>>>>> different
>>>>>>>>>>>> ordering for the mixed dofs than for the dofs of a regular
>>>> vector
>>>>>> valued
>>>>>>>>>>>> function?
>>>>>>>>>>>>
>>>>>>>>>>> I don't think so. For both mixed and vector elements, dofs at
>>>> the
>>>>>> same
>>>>>>>>>>> node do not lie next to each other in the dof mapping.
>>>>>>>>>>>
>>>>>>>>>>> It will be possible to choose the dof ordering soon when the
>>>> new
>>>>>>>>>>> assembly is  up and running. There is already a new class
>>>> DofMap
>>>>>> which
>>>>>>>>>>> will handle this.
>>>>>>>>>>>
>>>>>>>>>>> Garth
>>>>>>>>> Generally, you can never be sure how the dofs are ordered. This
>>>>>> could
>>>>>>>>> potentially change between different versions of FFC or between
>>>>>>>>> different form compilers. As long as the generated code follows
>>>> the
>>>>>>>>> UFC specification, the dof maps may be different.
>>>>>>>>>
>>>>>>>> This sounds strange. DofMap will provide the functionality to
>>>>>> influence
>>>>>>>> the dof mapping. UFC should provide the input to DofMap, but the
>>>> user
>>>>>>>> should then be able to manipulate it if they wish.
>>>>>>> I don't mind documenting how FFC actually orders the dofs, but the
>>>>>>> idea of the UFC interface is that one should not need to know
>>>> intimate
>>>>>>> details of FFC to work with the generated code.
>>>>>>>
>>>>>> What I'm trying to say is that a user should be able to influence
>>>>>> the
>>>>>> dof mapping through the public member functions of dolfin::DofMap.
>>>> They
>>>>>> don't need to know the details of FFC, or even UFC.
>>>>> Then I understand and I agree!
>>>> That sounds good; so we all agree for future design that it should be
>>>> clear to the user how the dofs are ordered, and the user should have
>>>> full
>>>> access to manipulate the ordering through an interface such as
>>>> dolfin::DofMap.
>>> I'm not sure we agree completely yet. I was thinking the DofMap class
>>> should take whatever dof ordering comes out of FFC and then apply
>>> different reordering algorithms on this dof ordering (if necessary).
>>>
>>> A user of DofMap can say: reorder the dofs by this algorithm or by
>>> this algorithm. For example: reorder the dofs by Cuthill-McKee. It's
>>> not clear to me a user can say: order the dofs in this very particular
>>> way:
>>>
>>>     first vertex degrees of freedom for the first component
>>>     then edge degrees of freedom for the first component
>>>     first vertex degrees of freedom for the second component
>>>     then edge degrees of freedom for the second component
>>>
>>
>> Ok. As a Dolfin developer/user I find this a bit unsettling; to not be
>> able to access the underlying ordering. It goes into the core idea of
>> Dolfin to be able to access the FEM structures on different levels,
>> including the lowest possible one. Without this possibility it appears
>> that you will have to dig into FFC or even UFC to access this
>> information,
>> which would appear to go against the idea of Dolfin and FFC to be
>> stand-alone packages with a UFC in between (and similar for PyCC etc.)?
>>
>
> dolfin::DofMap should/can be constructed to return whatever is needed,
> in addition to renumbering, etc.

Sounds good!

>>>> We have to allow for also this low level manipulation of the functions
>>>> since we will not be able to cover all possible functionality with
>>>> high
>>>> level interfaces at this point.
>>> What is it you need to do?
>>
>> In developing Dolfin I would like to access this information in the
>> process of debugging, add functionality relating to particular dofs (it
>> can be useful to know what are nodal/edge dofs for example), i/o when
>> dealing with external formats, adding preliminary functionality which is
>> not yet implemented in FFC,...
>>
>>> The UFC specification is still up for review. If it looks like we have
>>> missed something important, we need to know so we can decide if it is
>>> covered by the current specification or if we need to add something to
>>> the interface.
>>
>> I think it is good that you are including (I assume it was decided so)
>> the
>> option of integration over subdomains/-surfaces in one form. You would
>> also like to access mesh geometry such as normals and tangents,
>> cell/face
>> sizes etc. in the form. I am not updated on UFC of today, so maybe it is
>> already covered.
>>
>
> I would like to see the functionality to define functions on entities
> with topological dimension different from the geometric dimension (like
> on triangles in 3D). Then things like normals and tangents can be
> treated as functions.  I think that it's better to keep mesh geometry
> out of the form compiler.

Yes, this may be the best way to go. Such an extension should not be to
hard, as far as I can see.

/Johan

>> Unfortunately, I think it is hard to once for all define a UFC
>> specification that will cover what you will need as a PDE-modeller. I
>> think it is very wise to build a structure for UFC which allow for
>> continuous improvements. But I assume that this is what you do.
>>
>
> I agree about UFC. I think that we'll see what we really need when
> we start using it. Don't get too attached to the new UFC standard :).
>
> Garth
>
>>> Also, take a look at the current thread
>>>
>>>     "create_sub_element (mixed functions)"
>>>
>>> on ufc-dev which I think is very much related to this issue.
>>
>> Ok.
>>
>> /Johan
>>
>>
>>> /Anders
>>> _______________________________________________
>>> UFC-dev mailing list
>>> UFC-dev@xxxxxxxxxx
>>> http://fenics.org/mailman/listinfo/ufc-dev
>>>
>>
>>
>> _______________________________________________
>> UFC-dev mailing list
>> UFC-dev@xxxxxxxxxx
>> http://fenics.org/mailman/listinfo/ufc-dev
>>
>
>
>