On 2 September 2013 13:54, Jan Blechta <[email protected]> wrote:
> On Mon, 2 Sep 2013 13:20:46 +0200 > Martin Sandve Alnæs <[email protected]> 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. > > In principle you're right. Problem is that > > 1. there is an issue https://bugs.launchpad.net/dolfin/+bug/1081635. > > 2. mechanism of reordering user's data not supplied within mesh (but > still dependent on mesh ordering) is not available > > > > > Dolfin needs functionality for conversion between MeshFunction<float> > > and Function, the most typical cases are cell and vertex data: > > Yeah and this is what `vertex_to_dof_map` is for. There should be also > `cell_to_dof_map` for DG spaces. > > > > > 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 > > Do you think that you can handle all the combination of function spaces > and entity functions robustly? Maybe you finally end up doing projection > or interpolation which is what one wanted to avoid so > introduced `vertex_to_dof_map`. > > Jan No, the point here is to transfer vertex or cell data (or _maybe_ something slightly more general) into a function for simple elements only. The user can then do whatever projections into fancy elements he wishes. Martin
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
