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