On Fri, 14 Mar, 2014 at 12:21 PM, Martin Sandve Alnæs
<[email protected]> wrote:
I'm already in the process of implementing from the UFL/UFLACS(FFC)
side, and getting fundamentals fully in place there will be the
leading priority. By using a regular Coefficient for x everything
falls into place quite nicely, and I'm doing other symbolic geometry
as well that simplifies a lot of things.
I don't think we've discussed how this should be done on the FFC side.
One extreme is that the map is provided as a Function, and FFC handles
the Jacobian computation, etc using the Function. Other cases are that
UFC provides an interface function that given a parent coordinate
returns the map and Jacobian at that point, or ufc::cell stores
'higher-order node' coordinates that can be used to construct a
polynomial map in the generated code.
I'm not challenging (yet :)) what's being done - I'd just like to know
if there is a plan.
Answering Garths comments:
Doing boundary cells only will require generating an additional
tabulate-tensor implementation as well as other details which will
lead this discussion into information overload. We'll have to push
that to a later stage, maybe it will be easier after we have better
designed support for functions on submeshes/restrictions/whatever we
call them.
I think it should be considered now since it will affect the choice of
data structure/implementation, e.g. it immediately discounts using
dolfin::Function without major changes to Function.
Doing non-polynomial mappings would basically involve introducing
callable functions to UFL, which can be useful in other contexts as
well. Getting the framework in place for defining x as a Coefficient
in UFL and a Function in DOLFIN will be the first step (which is
already well underway). By later introducing the "space of functions
that can be evaluated in quadrature points" (including derivatives)
should then sort out the arbitrary mappings you want as a side effect.
So I say getting in place coordinates represented by any vector
valued finite element function is a pretty good first step.
In terms of implementation I agree, in terms of deciding how we start
to go about now is the time to think forward. Deliberating implicit in
the two cases that I presented is that they both discount using
dolfin::Function.
Answering Anders comments:
I think the right place to get the coordinate function from is the
MeshGeometry.
It should be accessible from the Mesh, because the UFL abstraction is
SpatialCoordinate(domain)
Jacobian(domain)
etc.
and ufl.Domain carries the dolfin.Mesh as domain.data().
So if we can add a member
shared_ptr<Function> MeshGeometry::coordinate_function()
that returns nullptr for meshes without a coordinate function set, I
think that's enough for now and I can try to get the basics working.
I don't get why we would want a dolfin::Function with all the extras
that come with it. For the isoparametric case, we just need need an
interface that supplies the coordinates of 'higher-order' points in
addition to the vertex coordinates. We could also associate a
dolfin::FiniteElement with mesh geometry to provide and complete
definition of the coordinate field.
Garth
Martin
On 13 March 2014 22:35, Garth N. Wells <[email protected]> wrote:
On 13 Mar 2014, at 21:36, Martin Sandve Alnæs <[email protected]>
wrote:
> For nonaffine geometries it would be much cleaner if the mesh
coordinates were always represented by a Function.
>
I would suggest starting the discussion with what we need, and leave
how we do it (i.e., implementation aspects) to the next step. For
example, what maps do we want to support? (I would like user maps to
be possible, which might not be polynomial functions.) Do we want
optimised support for the common and practical case that only cells
on the boundary are non-affine?
Garth
> In the initial iteration this can be made working by essentially
ignoring the mesh.geometry() in the assembly, but to get that
working it must be special cased in various places around dolfin.
>
> So it would be much nicer if MeshGeometry could simply be a
Function. Or optionally have a Function, maybe that's easier to do.
The problem is circular dependencies, which are in a way caused by
the grouping of geometry and topology in the mesh.
>
> I don't really have a question at this point, just want to let
everyone know that this is an issue that needs considering from
various angles.
>
> Martin
>
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
