On Thu, Oct 09, 2014 at 02:08:55PM +0100, Garth N. Wells wrote: > > > On Thu, 9 Oct, 2014 at 2:02 PM, Anders Logg <[email protected]> wrote: > >On Thu, Oct 09, 2014 at 12:06:51PM +0100, Garth N. Wells wrote: > >> > >> > >> On Thu, 9 Oct, 2014 at 10:03 AM, Chris Richardson > >> <[email protected]> wrote: > >> >On 08/10/2014 22:13, Anders Logg wrote: > >> >>To what extent is MeshData still in use? > >> >> > >> >>I noticed today that "facet_orientation" is still supported by the > >> >>assembler, but it is assumed to be stored as part of MeshData > >>and it > >> >>is no longer possible to attach any data to MeshData... > >> > > >> >I think it still works from C++. It is also used for storing > >> >"parent_cell" information from refinement algorithms. > > > >Does it? > > > >std::shared_ptr<dolfin::MeshFunction<std::size_t> > > >MeshData::create_mesh_function(std::string name) > >{ > > dolfin_error("MeshData.cpp", > > "create a MeshFunction via mesh data", > > "MeshFunctions can no longer be stored in MeshData. Use > > arrays instead"); > > > > return std::shared_ptr<MeshFunction<std::size_t> >(); > >} > > This type of function is a problem because it introduces a circular > dependency. A Mesh should not hold MeshFunction objects to avoid the > circular dependency.
Now I see what the problem is. I got a user question regarding the creation of data for facet_orientation based on an old example which used MeshFunction. Arrays are indeed supported (both by Assembler.cpp and MeshData.cpp). So let's just keep it as is, unless you have a good suggestion for where to store facet_orientation. -- Anders > Garth > > > > >> >It is useful to have auxiliary mesh data, and MeshData is useful > >> >to have for testing out new ideas. > > > >I agree it is useful for data structures that are either > >"usef-defined" (and thus not recognized by the library) or data > >structures that are experimental/undocumented. > > > >> >For established concepts, such as facet_orientation, or > >> >parent_cell, maybe they should go somewhere else? > >> > >> Yes, they should have their own dedicated data structures. > > > >Perhaps in the case of parent_cell, but I would say facet_orientation > >is still somewhat experimental/undocumented and could therefore reside > >in MeshData. (Storing in MeshData is convenient and it avoids > >cluttering of existing data structure.) > > > >But I wouldn't mind moving it somewhere else - where? > > > >In any case, why do we need to throw an error in case we agree > >MeshData can be used for aixiliary/experimental data? > > > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
