Hello, Roy and John, Thank you very much for your feedback. Yes, I am working with a mesh that is too big. Either a mesh of 1024^3 cells or a mesh of 256^3 cells that is further refined adaptively to get a local resolution of 1024^3. It can be opened on a single processor subject to the available memory but I like to read and write in parallel, having the mesh distributed at each time step. Even with a smaller mesh, it is question of "algorithmic" view, if I can do so, and if I can utilize libMesh for this. I fully understand John's work around.
I agree with Roy that serialized meshes are sometimes useful. However, I need to deal with a large mesh and associated solution vector, and read the transient data for post-processing purpose - for which parallel read/write is useful. If I understood Roy, I could use either Nemesis format or Checkpoint format for parallel read/write. Please correct me if this is NOT the case. I will try these two formats. Thank you very much for helping computational researchers with the libMesh package. Regards, Jahrul On Mon, Dec 4, 2017 at 3:40 PM, Roy Stogner <[email protected]> wrote: > > On Mon, 4 Dec 2017, John Peterson wrote: > > On Mon, Dec 4, 2017 at 10:59 AM, Alam, Jahrul <[email protected]> wrote: >> >> Thanks for the clarification. Can you suggest a work around? If I do, >>> mesh0.read(lshaped_0.vtu) and mesh1.read(lshaped_1.vtu), and so on, is it >>> possible to end up with a DistributedMesh by combining mesh0, >>> mesh1,............. at the user level? >>> >>> Or, is there another format that supports parallel read and write? >>> >> >> I wouldn't worry about parallel read/write until you get to a point that >> you are working with a Mesh that's too big to even be opened on one >> processor. >> >> Your code can still run in parallel even when you read a mesh in serial. >> > > For the sake of completeness, I'll point out that you can read and > write distributed meshes in either the standard Nemesis format or in > a libMesh-specific (and libMesh-version-specific! beware!) > "Checkpoint" format. (Our libMesh-specific XDR format let you write > solution data in parallel, but not mesh data currently) > > I would definitely suggest taking John's advice, though. For archival > purposes of final solutions, serialized mesh files are just easier to > deal with. Parallel mesh files become useful when you have so much > data to write out (transient problem with a good solver with which you > want to make a movie?) that I/O becomes a bottleneck. > --- > Roy > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > -- ===================================== Jahrul Alam, PhD Assistant Professor, Dept of Mathematics and Statistics Memorial University, St John's, NL, Canada http://www.math.mun.ca/~alamj/ eMail: [email protected] Office: HH-3035, Tel: 709-737 8071 ===================================== ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
