> Hmm... they still may not be. If you do a System::reinit() after > coarsen/refine, the Mesh will also be repartitioned, and I don't know > that our partitioners (the default, METIS/ParMETIS, in particular) are > guaranteed to give you the same partitioning every time you give them > the same mesh - I suspect their results will depend on the previous > partitioning/ordering, which will be scrambled by the coarsen/refine. > The different partitioning will then give you different DoF indexing.
But really, do you think there is a need for redistribution of all the dofs ? I was thinking that each processor would handle coarsen/refine on its own and only the boundary elements need to update the data as to which other processor's elements it is still connected or needs data from. You could simply provide an option to handle this case if it was a multigrid context. Or am I trying to blow over a lot of things without knowing what is happening internally ? If that is a code-breaking change, I will verify with the developers of ParMetis if there is a way to obtain the initial distribution of the mesh exactly back based on some kind of constraints. I hope this is possible. >> Again, coming back to the allocation, if the mesh and dof_map are not >> reallocated essentially, > > Not sure what you mean by that. What I meant was that essentially you add or remove points from mesh and dof_map connectivity but it is not in a sense reallocating new memory as in the case of a solution vector since I need all the coarse and fine grid residuals in order to perform the prolongation and restriction. It is just something that came to my mind and thought that it is another change that is required. Well thanks for all the help till now guys. I've got a very good idea on where I would need to get my hands dirty and what I might have to do in case I start going this route. Have a good night and I'll get back on this topic tomorrow, with maybe fresh ideas. ~Vijay On Wed, Nov 12, 2008 at 10:21 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > On Wed, 12 Nov 2008, Vijay M wrote: > >> 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. > > Yes, definitely. > >> 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, > > Hmm... they still may not be. If you do a System::reinit() after > coarsen/refine, the Mesh will also be repartitioned, and I don't know > that our partitioners (the default, METIS/ParMETIS, in particular) are > guaranteed to give you the same partitioning every time you give them > the same mesh - I suspect their results will depend on the previous > partitioning/ordering, which will be scrambled by the coarsen/refine. > The different partitioning will then give you different DoF indexing. > > Really, this needs internal library development - we need to "coarsen > without *really* coarsening", so to speak, and that'll require at > least some DofMap and EquationSystems modification. > >> Again, coming back to the allocation, if the mesh and dof_map are not >> reallocated essentially, > > Not sure what you mean by that. > >> is the solution and local_solution vectors the only >> ones I need to worry about based on the mesh distribution? > > A System can have any number of vectors added, in some cases (like > transient systems' old solution vectors) "behind the user's back". > But they'll all get projected correctly (albeit perhaps too slowly) by > an EquationSystems::reinit(). > >> 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). > > Parallel adaptivity requires some synchronization. We don't do that > as efficiently as we should yet, but the results should be correct. > >> 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 > > Yes, but only if you've done an EquationSystems::reinit() first - > which as I said might also trash your partitioning. > --- > 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
