dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Sep 22, 2008 at 06:17:49PM +0200, Anders Logg wrote:
> 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.

I've added DynamicMeshEditor. Try to use this in PXMLMesh.cpp. It may
simplify it a bit.

-- 
Anders

Attachment: signature.asc
Description: Digital signature