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.)?
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.
