dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 05, 2007 at 12:26:10PM +0100, Johan Hoffman wrote:
> > On Mon, Feb 05, 2007 at 11:44:50AM +0100, 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.)?
> >
> > The idea of the UFC specification is to describe an interface between
> > form compilers (like FFC or SyFi) and form assemblers (like DOLFIN or
> > PyCC). You should be able to take a form compiled with any form
> > compiler that supports UFC and stick it into any form assembler that
> > supports UFC.
> >
> > One important part of the interface is the function
> >
> >     tabulate_dofs()
> >
> > which tabulates the global dof numbers for the dofs on an element.
> >
> > The arguments of the function tabulate_dofs() are covered by the UFC
> > specification, but how the dofs are ordered is not covered. The dofs
> > are ordered differently by FFC and by SyFi.
> >
> > How the dofs are actually ordered by FFC is no secret and it will be
> > documented completely in the FFC manual, but you should not need to
> > care about how the dofs are ordered, other than for debugging. If you
> > need to know the ordering for debugging, just look it up in the manual
> > or look at the generated code, which could say something like
> >
> >     dofs[0] = c.entity_indices[0][0];
> >     dofs[1] = c.entity_indices[0][1];
> >     dofs[2] = c.entity_indices[0][2];
> >     unsigned int offset = m.num_entities[0];
> >     dofs[3] = offset + c.entity_indices[1][0];
> >     dofs[4] = offset + c.entity_indices[1][0] + 1;
> >     dofs[5] = offset + c.entity_indices[1][1];
> >     dofs[6] = offset + c.entity_indices[1][1] + 1;
> >     dofs[7] = offset + c.entity_indices[1][2];
> >     dofs[8] = offset + c.entity_indices[1][2] + 1;
> >     offset = offset + 2*m.num_entities[1];
> >     dofs[9] = offset + c.entity_indices[2][0];
> >
> > (This example is UFC code generated for scalar degree 3 Lagrange
> > elements with the current development version of FFC.)
> >
> >> >> 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,...
> >
> > For debugging I understand you may need to know the particular
> > ordering, but do you really need it otherwise? Is there some specific
> > example you could give? If we have missed something in the UFC
> > specification, it is important that we know so we can correct it.
> >
> >> > 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.
> >
> > Yes, this has been fixed.
> >
> >> 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.
> >
> > This is not covered by the UFC. Instead, you need to define Functions
> > for these objects. DOLFIN then provides default implementations of
> > these functions. Currently the following functions are supported:
> >
> >     MeshSize
> >     InvMeshSize
> >     FacetNormal
> >
> 
> Yes this is probably better.
> 
> >> 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.
> >
> > The idea is rather to define an interface that can remain constant for
> > a long time, among other things to avoid incompatibilities between
> > different versions of FFC and DOLFIN.
> 
> Ok. With this motivation things makes sense, and I guess UFC should be
> kept to a minimum only dealing with essential information. But then
> FFC-Dolfin is coupled e.g. by a common ordering (contrary to maybe
> FFC-PyCC for example). Maybe you'll get by often without knowing this, but
> I think you may need it sometimes, even though you should get by most of
> the time with MeshFunction and interpolation using FFC.

FFC-DOLFIN should not be coupled, or more precisely they should only
be coupled through UFC interface. (The purpose of the UFC is to
specify exactly what the coupling is.)

/Anders

> /Johan
> 
> 
> > /Anders
> >
> >> > 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
> >> >
> >>
> >>
> >> _______________________________________________
> >> FFC-dev mailing list
> >> FFC-dev@xxxxxxxxxx
> >> http://www.fenics.org/mailman/listinfo/ffc-dev
> > _______________________________________________
> > UFC-dev mailing list
> > UFC-dev@xxxxxxxxxx
> > http://fenics.org/mailman/listinfo/ufc-dev
> >
> 
> 
> _______________________________________________
> FFC-dev mailing list
> FFC-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/ffc-dev