A little more info. Firstly, I recompiled in debug mode and I get this out when it tries to uniformly refine:
##### Assertion `min_procid != libMesh::processor_id() || obj' failed. [3] src/mesh/parallel_mesh.C, line 546, compiled Jun 23 2008 at 16:41:23 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic ##### I'm working on a stack trace - I'll send that when I get it. Secondly, I did some testing with example 10. It looks like if you turn coarsening off, it runs fine in parallel. However, if you change from refine_and_coarsen_elements() to uniformly_refine() it fails.... so there is something odd about uniformly_refine().... More info when I get it. Derek On Mon, Jun 23, 2008 at 4:34 PM, Derek Gaston <[EMAIL PROTECTED]> wrote: > Hmmm... uniformly refining a ParallelMesh that has had > delete_remote_elements() called on it is giving me a segfault. Is it > supposed to work? > > Derek > > On Mon, Jun 23, 2008 at 4:15 PM, Derek Gaston <[EMAIL PROTECTED]> wrote: >> Guys, >> >> What do I need to do to actually use ParallelMesh with parallel I/O? >> So far I've done --enable-parmesh and used delete_nonlocal_elements >> (after doing a build_cube)... then I've computed a solution and >> written a single exodus file. In writing that Exodus file is it >> serializing the mesh first? Or is it doing that block chunked I/O >> that Ben put into the code? Somehow it's getting all of the elements >> into that Exodus file.... >> >> Here's what I'm thinking I'd like to do: Let's say I have a coarse >> mesh in exodus format (all in one file) to start with. I want to read >> this in (preferably in parallel, even if that means I need to do an >> offline filetype conversion first) then uniformly refine it to >> saturate all available memory... compute a solution... then write it >> out (hopefully a parallel write... but doesn't have to be). >> >> Is that doable now? >> >> Also, how much work do you think it would be to be able to read (and >> write) decomposed Exodus files? The writing part sounds especially >> easy (I believe that decomposed Exodus files are just regular exodus >> files). >> >> The idea is that I'm going to be running a simulation that uses >> approximately 40 million elements on about 1,000 procs. What I do >> doesn't have to be pretty... it just needs to work. If the mesh I run >> on is just a cube... so be it... if it looks like a cylinder that >> would be a huge bonus. I am open to all ideas. >> >> Thanks! >> Derek >> > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
