Ben, I think i've heard the 'none of the active developers use mesh_data' answer before :) but do not worry about it. I just wanted to find out if there was any such existing method already.
I am looking into this currently and am now writing a method that does broadcast_mesh_data(MeshData&) in MeshCommunication. That way, you could just call this method from UnstructuredMesh right after the broadcast call on the mesh. Hopefully this should not take up too much time and I'll send you this function once I'm done writing and testing it. Vijay On Wed, Oct 29, 2008 at 4:36 PM, Kirk, Benjamin (JSC-EG) <[EMAIL PROTECTED]> wrote: > 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
