← Back to team overview

dolfin team mailing list archive

Re: DofMapSet design

 

Anders Logg wrote:
On Thu, Sep 18, 2008 at 10:18:13AM +0200, Anders Logg wrote:
On Thu, Sep 18, 2008 at 08:53:15AM +0100, Garth N. Wells wrote:

Niclas Jansson wrote:
Garth N. Wells wrote:
Niclas Jansson wrote:
Sounds good. Can you submit this in one or more patches, starting
with
the parallel XML parser?

Finally, the parallel XML parser.

Could you create a bundle against the dolfin-dev tip and re-send it? The
bundle was created against a relatively old dolfin-dev which makes
merging non-trivial.

Garth

This one should work, hopefully.

Thanks. I've just pushed it to dolfin-dev.

It would be good if all interseted parties could take a look and provide
feedback.

Garth
I will look at it later today.

I have started looking at the code. It seems to work fine, but it will
take me a while to get through it.

It would be helpful if you could add some more comments. There are
large chunks of uncommented code for example in PXMLMesh::closeMesh.


Ok.

I also wonder about the following in PXMLMesh::readVertices:

  const uint L = floor( (real) num_vertices / (real) num_processes);
  const uint R = num_vertices % num_processes;
  const uint num_local = (num_vertices + num_processes -
  process_number - 1) / num_processes;

  start_index = process_number * L + std::min(process_number, R);
  end_index = start_index + ( num_local - 1);

I think I can guess what it does, but does it have to be this
complicated? Isn't it enough to do something like

  const uint n = num_vertices / num_processors;
  start_index = n*process_number;
  end_index = start_index + n;

and then a fix for the last processor:

  if (process_number == num_processors - 1)
    end_index = num_vertices;

?

--
Anders


But shouldn't that give a bad load balance, for example when N is large, R << num_processes and (end_index - start_index) >> R.

Niclas




Follow ups

References