On 2 September 2013 13:36, Johan Hake <[email protected]> wrote: > On Monday September 2 2013 13:20:46 Martin Sandve Alnæs wrote: > > Some ideas then: > > > > File formats for MeshFunction should be used for storage of > mesh-associated > > data. Conversion tools relate to the file format, not to arbitrary > > reordering algorithms in dolfin. > > > > Dolfin needs functionality for conversion between MeshFunction<float> and > > Function, the most typical cases are cell and vertex data: > > > > V = CG1 space > > u = Function(V) > > m = MeshFunction("double", mesh, 0) > > u.assign(m) # Only valid if dofs are vertex associated > > m.assign(u) # Ditto > > > > V = DG0 space > > u = Function(V) > > m = MeshFunction("double", mesh, dim) > > u.assign(m) # Only valid if dofs are cell associated > > m.assign(u) # Ditto > > Sounds good. This should also be possible to extended to sub_function > assignments. > > > Although "double" is not sufficient for vector/tensor valued functions. > > There is nothing in C++ that prevents us to create a: > > MeshFunction<std::vector<double> > > > to cover that need. One would need to extend MeshValueCollection and the > File > format though. We might consider extend MeshFunction with value_rank and > value_shape to accommodate vector and tensor valued MeshFunctions.
Even if that works with all the templated MeshFunction code, it's way too slow to do dynamic allocation for each mesh entity. It has to be a fixed size type. Or as you mention extending MeshFunction to support value size. Or maybe we can build a macro-MeshFunction on top? Martin
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
