Re: [Libmesh-devel] Parallelizing the Mesh

[Roy S. <roy...@ic...>]

On Thu, 12 Jul 2007, John Peterson wrote:

> I think this definitely takes us in the right direction, though I don't
> doubt there will be several gotchas even with this first step.  We should
> also think about meshes which can't fit on a single processor...
>
> Such a mesh would be ungainly (how would we store it, multiple
> data files?)  but you can certainly build_square() something which
> is too large for a single CPU, and it would be cool if that eventually
> worked in parallel w/o ever having to store the whole thing on 1 CPU.

Absolutely.

I think Ben's got the right idea about storage (even though it makes
Mesh::read() tricky, since we'd have to make multiple passes to avoid
reading in too many elements/nodes at once).  What worries me about
meshes too big to fit on one node is repartitioning.  Will Parmetis
work that way?  The space-filling-curve repartitioners might be ideal
for use in parallel; putting all the elements in some 1D order is easy
to do in parallel, and then it's easy to negotiate which processors
get which elements.
---
Roy