Ahh... I missed the mesh_data part. I wish I had a better answer than 'none of the active developers use mesh_data'.
I'll look into the broadcast more and see if there might be a straightforward way to send out mesh data as well. -Ben ----- Original Message ----- From: Vijay S. Mahadevan <[EMAIL PROTECTED]> To: Kirk, Benjamin (JSC-EG) Cc: John Peterson <[EMAIL PROTECTED]>; [email protected] <[email protected]> Sent: Wed Oct 29 16:27:26 2008 Subject: Re: [Libmesh-users] Mesh reading in parallel Ben, 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 processor 0. 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. Vijay On Wed, Oct 29, 2008 at 2:36 PM, Benjamin S. Kirk <[EMAIL PROTECTED]> wrote: > John, > > 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 > go. > 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 > job. > -Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
