Anders Logg wrote:
> I'm slowly working my way through PXMLMesh.cpp and I need some
> assistance (from Niclas).
>
> It all looks very good and I'm sure it works perfectly, but some work
> is needed to make it possible to read/understand:
>
> 1. PXMLMesh::closeMesh really needs some commenting. It's a large
> chunk of nontrivial and quite complex code so a whole lot of
> commenting is needed.
I'm working on it.
>
> 2. Why is the mesh editor closed in PXMLMesh::readCells and then
> opened again later in PXMLMesh::closeMesh?
>
> If we can't write to the mesh until everything is read in, then maybe
> we should wait with initializing anything until closeMesh() and at
> that point start editing the mesh?
>
It's a (ugly) workaround due to the static nature of the MeshEditor
(number of vertices must be specified a priori). It could of course be
fixed by moving the geometric partitioner inside the parser, and only
opening the editor inside closeMesh().
However the nice solution would be to make the MeshEditor more dynamic.
That would also make life easier when implementing a better refinement
algorithm (for example, the recursive longest edge bisection (Rivara)
from unicorn)
> 3. I don't understand the logic in readTriangle/readTetrahedron.
> What does the following code do?
>
> if (!(is_local(v2) || is_local(v1) || is_local(v0)) || !is_local(v0))
> return;
>
> used_vertex.insert(v0);
> if (is_local(v1))
> used_vertex.insert(v1);
> if (is_local(v2))
> used_vertex.insert(v2);
>
> if (!(is_local(v1) && is_local(v2) && is_local(v0)))
> {
> if (!is_local(v1))
> shared_vertex.insert(v1);
> if (!is_local(v2))
> shared_vertex.insert(v2);
> }
>
The idea is to assign the triangle/tetrahedron to the processor who owns
vertex v0. And, yes the logical could probably be more clearer.
The used_vertex part marks which of the locally stored vertices that a
processor have used. Since some of them are going to be unused, they
"must" be moved of the processor in a later stage.
The shared_vertex parts marks which vertices not present at the
processor a cell is using.
> I've added the function is_local to make it more readable but it's
> still not clear to me what happens.
>
While parsing the cells, a processor must decide if it have the parsed
global vertex number.
Instead of search trough the mesh function of global numbers, all
numbers are placed in a std::set (after the geometric partitioner), so
that lookups could be made in a reasonable amount of time ( O(log n) if
I remember correctly).
The best solution would of course be to implemented some kind of hash table.
> 4. The above logic seems to be missing in readInterval.
Yes, I simply forgot to add it.
Niclas
>
> --
> Anders
>
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
