Currently, I do read the file via MeshBase::read() but since you do
not distribute the mesh_data information along with the mesh (even
though I pass it to the read function), I seem to have quite a few
problems. My code primarily relies on mesh_data information to
associate material data, attributes to elements and nodes and I was
thinking that probably MeshCommunication had some way to distribute
this. After looking mroe in to the code, I saw that only the
boundarynodes are communicated and the mesh_data is available only to
I have not tried using the MPI IO functions before and it just
occurred to me as a possible option. I understand what you are trying
to say regarding the intricacies involved with such an implementation.
I probably will wait for you guys to develop and test NemesisIO code
since currently I'm not worried too much about the mesh reading
performance as compared to the rest of my code.
Anyway, do let me know if you got more suggestions regarding the
mesh_data distribution. Thanks again.
On Wed, Oct 29, 2008 at 2:36 PM, Benjamin S. Kirk
> Thanks for the quick reply !
> I was just reading about MPI File Read functions
> (http://www-unix.mcs.anl.gov/mpi/www/) and I'm thinking that this is
> possible without too much of a hassle. If we can make the mesh readers
> take the stringstream as input instead of IFstream, there is
> absolutely nothing that needs to change. Based on the attributes, the
> partition can be ascertained and each processor needs to read only
> those elements and nodes. But, I guess it is easier said than done !
> I will look into the MeshCommunication class and see if that will
> provide a quick fix for my problems. I'll keep you updated if I get
> enough time to try out the previous option.
> how exactly are you trying to read the file? If it is done through the
> generic MeshBase::read() member then, as John says, the parallel part should
> be handled for you. Processor 0 will read the entire mesh and then
> broadcast it. When MeshBase::read() exits all processors will be ready to
> As for using MPI's IO functionality, it really depends on the mesh format if
> this will be easy to do or not. If the format is such that the partitioning
> is easily specified or inferred, and each processor can compute its offset
> easily, then it really is easy. Each processor just opens the file and
> seeks to the proper location. You gotta be careful, though, that you don't
> exceed the capability of the filesystem... If you do this with say 128
> processors to an NFS filesystem you will almost certainly kill your machine.
> The NemesisIO work is in development, and the reworked XDA/XDR format is
> intended to be easily handled in parallel as well. Once it is all completed
> it should be possible to serially convert an arbitrary file format to one of
> the 'preferred' parallel formats, then use that as input to the parallel