On Fri, Mar 14, 2014 at 01:32:00PM +0000, Garth N. Wells wrote: > > > 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.
What functionality does Function have that we don't want for a CoordinateFunction? - Perhaps the possibility to extract subfunctions? - What about dofmap? Would it be enough with a fixed scheme (for ordering the coordinate values) or will we at some point want to reorder the list of coordinates? - When I think of it now, the biggest difference is that we don't need to store the values in a GenericVector since I don't see a need for sending that data to a linear solver (ever). So in conclusion, perhaps we will need to implement a new class CoordinateFunction which implements the GenericFunction interface but is otherwise different from Function. -- Anders _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
