Hi
Nice to know you're immediately on top of this:-)
One comment is necessary regarding freeing memory by clearing connectivities
that are no longer needed. The MeshConnectivity._connections storage is an
std::vector and mesh.clean() calls _connections.clear(). This sets the size of
the vector to zero, but it does not actually free any memory. (Just try
mesh.clean() after mesh.init() and monitor the memory usage.) To actually free
memory I have found this solution (from
www.cplusplus.com/reference/vector/vector/clear/)
diff --git a/dolfin/mesh/MeshConnectivity.cpp b/dolfin/mesh/MeshConnectivity.cpp
index f2ab191..a6ade06 100644
--- a/dolfin/mesh/MeshConnectivity.cpp
+++ b/dolfin/mesh/MeshConnectivity.cpp
@@ -59,8 +59,8 @@ const MeshConnectivity& MeshConnectivity::operator= (const
MeshConnectivity& con
//-----------------------------------------------------------------------------
void MeshConnectivity::clear()
{
- _connections.clear();
- index_to_position.clear();
+ std::vector<unsigned int>().swap(_connections);
+ std::vector<unsigned int>().swap(index_to_position);
}
//-----------------------------------------------------------------------------
void MeshConnectivity::init(std::size_t num_entities, std::size_t
num_connections)
Any objections if I make this a pull request? Furthermore, clear() is used
quite extensively so I can't help thinking that freeing memory is relevant also
for other parts of the code?
Mikael
Den Jan 8, 2014 kl. 6:17 PM skrev Anders Logg:
> On Wed, Jan 08, 2014 at 05:00:20PM +0000, Garth N. Wells wrote:
>> On 2014-01-08 16:48, Anders Logg wrote:
>>> On Wed, Jan 08, 2014 at 04:41:17PM +0000, Garth N. Wells wrote:
>>>> On 2014-01-08 16:17, Anders Logg wrote:
>>>>> On Wed, Jan 08, 2014 at 04:07:35PM +0000, Garth N. Wells wrote:
>>>>>> On 2014-01-08 15:21, Anders Logg wrote:
>>>>>>> I would claim that the connectivity is stored very efficiently. The
>>>>>>> simplest example is D--0 connectivity for a mesh which is for each
>>>>>>> cell which vertices belong to it. That data is stored as one big array
>>>>>>> of integers, something like
>>>>>>>
>>>>>>> 0 1 2 3 0 1 2 4 ...
>>>>>>>
>>>>>>> which means that tetrahedron 0 has vertices 0 1 2 3, tetrahedron 1 has
>>>>>>> vertices 0 1 2 4 etc.
>>>>>>>
>>>>>>> There are D + 1 different kinds of entities in a mesh. For a
>>>>>>> tetrahedron we have vertex, edge, face, cell and so the total number
>>>>>>> of connectivities that may be computed is (D + 1)*(D + 1). Not all
>>>>>>> these are needed, but they can all be computed.
>>>>>>>
>>>>>>> For solving Poisson's equation, we first need D--0. To see which
>>>>>>> connectivities are computed, one can do info(mesh, True) to print the
>>>>>>> following little table:
>>>>>>>
>>>>>>> 0 1 2 3
>>>>>>> 0 - - - -
>>>>>>> 1 - - - -
>>>>>>> 2 - - - -
>>>>>>> 3 x - - -
>>>>>>>
>>>>>>> To set boundary conditions, one needs to create the faces of the mesh
>>>>>>> (which are not stored a priori). One will then get the following
>>>>>>> connectivities:
>>>>>>>
>>>>>>> 0 1 2 3
>>>>>>> 0 - - - x
>>>>>>> 1 - - - -
>>>>>>> 2 x - - -
>>>>>>> 3 x - x x
>>>>>>>
>>>>>>> Here we see the following connectivities:
>>>>>>>
>>>>>>> 3--0 = the vertices of all cells = the cells
>>>>>>> 0--3 = the cells connected to all vertices
>>>>>>> 3--3 = the cells connected to all cells (via vertices)
>>>>>>> 2--0 = the vertices of all faces = the faces
>>>>>>> 3--2 = the faces of all cells
>>>>>>>
>>>>>>> These get computed in order:
>>>>>>>
>>>>>>> 0--3 is computed from 3--0 (by "inversion")
>>>>>>> 3--3 is computed from 3--0 and 0--3
>>>>>>> 2--0 and 3--2 are computed from 3--3 by a local search
>>>>>>>
>>>>>>> 3--3 is needed in order for a cell to communicate with its neighboring
>>>>>>> cells to decide on how to number the common face (if any).
>>>>>>>
>>>>>>
>>>>>> 3--3 connectivity is *undefined*.
>>>>>
>>>>> Yes, in general, but we have *chosen* to define it as 3--0--3.
>>>>>
>>>>
>>>> Which I think we should attempt to remove
>>>>
>>>>> The reason for this choice is that we start with 3--0, from which we
>>>>> can easily compute 3--0--3.
>>>>>
>>>>> In other words, we start with cell-vertex data and hence the only way
>>>>> for two cells to figure out if they share common entities (for example
>>>>> faces) is to go via the vertices. Unless you have some other brilliant
>>>>> idea.
>>>>>
>>>>
>>>> The function GraphBuilder::compute_local_dual_graph does this. It
>>>> loops over cells and builds a hashed map (boost::unordered_map) from
>>>> a (sorted) vector of the facet vertices to the cell index. If the
>>>> key (the facet vertices) is already in the map, then we know a cell
>>>> that the current cell shares a facet with. If the key is not already
>>>> in the map, then we add it. With appropriate hashing, the
>>>> unordered_map look-ups are O(1).
>>>
>>> Now that's a brilliant idea. Why is this not already the default?
>>>
>>
>> Reluctance to touch the beautifully crafted mesh library? :)
>
> :-)
>
>> I'll
>> add it alongside the current code so that we can test it for speed.
>
> Great.
>
>> It's used in GraphBuilder to construct a dual graph (cell-facet-cell
>> connections) to feed to a graph partitioner because in GraphBuilder
>> we don't yet have a Mesh object - just cell connectivity data.
>>
>>> Application of boundary conditions can bypass TopologyComputation.cpp
>>> and build the facets using the dual graph and it would not be in
>>> conflict with TopologyComputation.cpp (which may still be useful for
>>> computing other connectitivies).
>>
>> The approach in GraphBuilder::compute_local_dual_graph could be used
>> for other connection types.
>
> Definitely. The current (old) approach was implemented based on the
> belief that mesh-wide hash maps would be very expensive and that
> the only sane option was local searches.
>
> --
> Anders
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
