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