dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Aug 24, 2011 at 08:43:40AM -0400, Garth N. Wells wrote:
>
>
> On 24/08/11 08:07, Anders Logg wrote:
> > On Wed, Aug 24, 2011 at 07:22:53AM -0400, Garth N. Wells wrote:
> >>
> >>
> >> On 24/08/11 03:50, Anders Logg wrote:
> >>> What is the plan for XMLLocalMeshData (using the DOM interface) vs
> >>> XMLLocalMeshDataDistributed (using the SAX interface)?
> >>>
> >>
> >> Both for the time being.
> >>
> >>> Reading boundary indicators is currently failing with
> >>>
> >>> RuntimeError: *** Error: Inconsistent state in XML reader: 6.
> >>>
> >>> Should this be fixed in XMLLocalMeshDataDistributed or is the plan to
> >>> replace it with XMLLocalMeshData?
> >>>
> >>
> >> In XMLLocalMeshDataDistributed.
> >
> > Could you elaborate? The functionality for reading and distributing
> > boundary markers (in parallel) is currently broken and we want to fix
> > it. But we need to know more about the design. I don't want to fix
> > something if you decide to break it 5 min later.
> >
>
> It never 'properly' worked in parallel. There were some messy ad hoc
> changes made on top of functions that were planned for overhaul. I made
> clear before this that parallel functionality was being sorted out (it's
> not just in io, but also partitioning, etc), so the fact that it's not
> working now should not be a surprise.

It came as a surprise since there was a unit test for it and the unit
test was removed. But nevermind, the important thing now is to get it
working again.

> There is a lot of missing functionality is parallel, so patience is
> required to get things done properly.
>
> > Should we continue to use libxml2? Why not use the DOM parsing all the
> > way?
> >
>
> Because I'm inclined to keep SAX parsing for meshes since meshes are the
> most likely to be created externally, and need to be scalable for
> reading. Other objects (e.g., vectors) are likely to be created and
> written by DOLFIN, so will eventually use parallel HDF5 for scalable
> parallel io.

The reason I once chose to implement the XML parsing using SAX, and
why Ola decided to use SAX in his rewrite 2 years back, is exactly
that: scalability and efficiency. I don't see why it should be
different for meshes than any other objects. Other objects can also be
large. It seems messy to use both.

> > What is the difference between XMLLocalMeshData and
> > XMLLocalMeshDataDistributed etc.
> >
>
> Initially I planned to use DOM for all, but as outlined above decided
> after some testing to retain SAX for meshes (but update to SAX2, since
> the libxml2 SAX parser is deprecated and has memory leaks). Hence,
> XMLLocalMeshData uses DOM and XMLLocalMeshDataDistributed uses SAX. So
> far I've kept the DOM version since it's easy to code and could be
> useful when reading non-distributed meshes on each process (which may
> differ on different processes).

I don't understand the difference between XMLLocalMeshData and
XMLLocalMeshDataDistributed. Is XMLLocalMeshDataDistributed doing now
what XMLLocalMeshData did before?

--
Anders