> > 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 ? > -----Original Message----- > From: Roy Stogner [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 12, 2008 7:02 PM > To: Vijay S. Mahadevan > Cc: [email protected] > Subject: Re: [Libmesh-users] Multigrid techniques with libmesh > > > On Wed, 12 Nov 2008, Vijay S. Mahadevan wrote: > > > I am curious on the concept of the 'view' of a mesh. > > > Basically, we store hierarchic meshes like this: > > *-----------*-----------* > *-----*=====*=====*=====* > *==*==* > > Where the mesh is 1D, there are 5 active elements and 3 ancestor > elements. > > We can also store meshes like this: > > *-----------*===========* > *=====*=====*.....*.....* > *..*..* > > Where there are 3 active elements, 1 ancestor element, and 4 > "subactive" elements". Looping over active elements just gets you the > ones in the active view, but the subactive elements and their > associated Dof objects still exist. We use this for coarsening > non-Lagrange elements properly, but it could make geometric multigrid > possible too. > > > 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. > > We could, however, create a "rerefine" method that jumps you straight > back to the finest mesh by making any active element with children > into an ancestor and making any subactive element without children > active. > > > If the dof_map and mesh can provide views that are consistent with > > the refinement or coarsening based on an initial mesh, then I do think > > this should be possible without too much programming effort for an > > external user. > > Ideally the external user shouldn't need to do anything that he isn't > already other than set some solver options or choose a different > solver object. > > But that implies the existence of an internal developer with the time > and expertise to do the library work, and such a person may not exist > right now. > > > Of course, you would also have to propagate the mesh_data (Or again, > > am I the only one using this ?) which stores material > > information/element or create a view of it also. > > You may be the only one using this. ;-) But yes, we'd want to handle > its restriction as well. > --- > 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
