dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Sep 22, 2008 at 06:13:34PM +0200, Niclas Jansson wrote:
> Anders Logg wrote:
> > On Mon, Sep 22, 2008 at 05:03:59PM +0200, Niclas Jansson wrote:
> >> 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.
> > 
> > ok, nice.
> > 
> >>> 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)
> > 
> > I agree it would be better to make MeshEditor dynamic. The problem is
> > that this is not always needed. Perhaps we should add a new class
> > DynamicMeshEditor that can be used when one does not know the number
> > of vertices and cells a priori.
> > 
> > It could be very simple, just storing the dynamic data in suitable STL
> > containers and then calling MeshEditor in close().
> > 
> >>> 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.
> > 
> > ok, I see.
> > 
> > It seems that
> > 
> >   !(is_local(v2) || is_local(v1) || is_local(v0)) || !is_local(v0)
> > 
> > is equivalent to
> > 
> >   (!is_local(v2) && !is_local(v1) && !is_local(v0)) || !is_local(v0)
> > 
> > which is equivalent to
> > 
> >   !is_local(v0)
> > 
> > Is this correct, and is this what you have in mind?
> 
> It looks correct to me. Seems like I should refresh my logic, that was a 
> really simple reduction :)
> 
> Niclas

It wasn't very obvious that it could be so much simplified, but it
should help to clear up the logic.

I'll wait for you to do some more work on PXMLMesh.cpp before I
continue reading it.

If possible, I'll add DynamicMeshEditor later tonight so you can use
that to simplify PXMLMesh.cpp further.

-- 
Anders

Attachment: signature.asc
Description: Digital signature