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> >();
}
> >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?
--
Anders
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
