Ahh. Now I see what you mean. Yes, in order to avoid it, I'm going to make the conscious decision to start from a coarse mesh that resolves all the boundaries and material interfaces correctly and then use that as the coarsest mesh. Now, if I refine this uniformly twice and keep that as my true mesh, I can coarsen it twice and get back to the original mesh I started with. I hope that is correct.
If this makes sense, I think I have a nice place to start working on this. And as long as coarsen and refine are pseudo-inverse operations, I should be able to propagate material data, boundary data correctly without any problems and perform the whole operation matrix-free except for the coarsest mesh solve. Again, coming back to the allocation, if the mesh and dof_map are not reallocated essentially, is the solution and local_solution vectors the only ones I need to worry about based on the mesh distribution ? I also assume that when you perform the refine and coarsen operations, it would still work in parallel since every proc only has to take care of its own elements (hmm, I'm not sure about this though). What I am getting at here is that when I call update() on system, would the new dof mapping be used correctly to get the scatter list ? If this is the case, that is fantastic. > -----Original Message----- > From: Roy Stogner [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 12, 2008 9:53 PM > To: Vijay M > Cc: [email protected] > Subject: RE: [Libmesh-users] Multigrid techniques with libmesh > > > > On Wed, 12 Nov 2008, Vijay M wrote: > > >>> For example when I have an unstructured grid, and when I coarsen > >>> uniformly twice and refine uniformly twice, would I get the exact > >>> same mesh?! > >> > >> No. For instance, the second mesh above is a uniform coarsening (so > >> far as such a thing exists) of the first mesh, but uniformly refining > >> it will produce two new elements that weren't in the first mesh. > > > > I do not understand this. I thought you maintained the level number for > each > > element and so once I specify an initial mesh, all elements in it are > > treated as level_0. Now if I refine it once, all new elements get the > > level_1 flag and become active while the original elements still are in > > memory but inactive. And now if I coarsen the mesh uniformly, then the > > level_1 elements become inactive and level_0 elements become active. > > > > Isn't this how the refine-coarsen methodology implemented ? Or am I way > off > > in my understanding ? > > That's exactly how refine-coarsen is implemented, and refine*N > followed by coarsen*N will always give you the same mesh. > > But coarsen*N followed by refine*N will not. Again, take a look at > mesh 2 in my last email to see why. > --- > Roy ------------------------------------------------------------------------- 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
