OK. I remember I tried to removed the is_serial() test before and ran into some "magic number" mismatch error and I gave up. Just now I repeated the experiment and found I could run it correctly. I could see reasonable repartitioning results. I will continue to play with it and if I meet the error again, I will report it here.
Thanks a lot. --Junchao Zhang On Wed, Aug 5, 2015 at 3:15 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > On Wed, 5 Aug 2015, Junchao Zhang wrote: > > In addition, I did more experiments. I increased the input mesh size, let >> it has 64 elements and ran with 12 processes. It looks libmesh keeps the >> original partition (got when the mesh is read in) unchanged, and does not >> do repartitioning after refinement. I observed it from viewing output mesh >> in paraview. >> So the question is under what conditions mesh repartitioning will be >> triggered in libmesh? >> > > My apologies for not jumping in to this discussion sooner. > > To the best of my recollection: ParallelMesh was originally developed > with no support for repartitioning (because just getting it working at > all was chore enough), which was therefore disabled, but support for > repartitioning was added later. > > Since obviously we *aren't* repartitioning, my recollection must be > wrong. There's a slim chance that I added repartitioning capability > but forgot to reenable it (go ahead and remove that is_serial() test > and try?), but more likely I added *some* of the underlying support > but not enough to get it working before I had other tasks take > priority. > --- > Roy > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
