From: KIRK, B. (JSC-E. (NASA) <ben...@na...> - 2005-03-08 19:29:31
|
This is why I was thinking we needed a separate step, restrict_vector. Things get a little complicated, however. The original intent was to perform coarsening first and then refinement for memory purposes. Eventually the coarsening will occur, any required parallel mesh redistribution will be performed, and then the refinement. This allows parallel communication with the smallest amount of data. The other thing that will be a little complicated is the DOF indexing. Basically, the parent elements will need to have dof indices allocated while the children are still around. Here is what I think: - User provides an error indicator. This gets used to flag elements for coarsening and refinement. - DofMap provides new dof indices to parents with all children flagged for coarsening, if necessary. Note that at this time there are no new elements since refinement has not been executed, furthermore the children are still around since coarsening hasn't been executed. Note that for Lagrange type elements there will be no dof indices added at this time since the coarsened dofs are simply a subset of the current dofs. - The solution is restricted. - Elements are deleted in the coarsen step as is currently done. - Elements are added in the refine step as is currently done. - The solution is projected, as is currently done. The user code would translate to something like this: // Flag elements as COARSEN, REFINE, etc... mesh_refinement.flag_elements_by_error_fraction(...); // This will call System::restrict() for all our systems. Essentially this employs the DofMap // to give new DOF indices to the parent elements that are about to become active and then // restricts the solution vectors from the children onto the parents. Note that for strictly // Lagrange elements this could be omitted. equation_systems.restrict(); // Actually create and delete elements mesh_refinement.refine_and_coarsen_elements(); // This is essentially the old EquationSystems::reinit() member. equation_systems.project(); This seems like the best approach to me. Otherwise, I actually might prefer your idea of leaving the children around, albeit as inactive. Of course, I would want a Mesh::compress() member or something like that to get rid of these children after the projection is handled. You could make a case, at least for implicit systems, that the memory overhead would not be bad in this approach. You just want to make sure the projection is completed *and then* the inactive children get removed *before* the matrices get reallocated. In any case I'd rather not have the Systems delete the elements. From a philosophical point of view the Systems and Mesh classes should be as separate as possible. Looking forward to more discussion, -Ben -----Original Message----- From: lib...@li... [mailto:lib...@li...] On Behalf Of Roy Stogner Sent: Monday, March 07, 2005 1:21 PM To: lib...@li... Subject: Re: [Libmesh-devel] libmesh-0.5.0 On Wed, 2 Mar 2005, Roy Stogner wrote: > On Tue, 1 Mar 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote: > >> 2.) Handle solution restriction/prolongation for non-Lagrange element >> types. > > This is IMHO the most important thing we need before any of my > adaptivity code can go in a new release - right now I think if you try > to do a time-dependent adaptive problem with non-Lagrange elements and > you coarsen any elements it'll just silently introduce errors. Unfortunately, this is proving to be a little harder than expected. I can't project fine element data onto coarse element basis functions, because by the time project_vector gets called, all the fine elements have been deleted, and doing an accurate projection requires all the fine element basis functions. So, I need to fix that. Keeping fine elements around after coarsen() is called won't be hard; the question is when to delete them: Never deleting them (and just reusing them when future refinement is done) might be simplest, and wouldn't waste too much RAM in many applications, but I suspect anyone tracking moving shock waves would hate me. I'd like to delete them during the system reinit(), but I'd like to run that idea by everyone first. In all the example code, refine_and_coarsen_elements() is always immediately followed by a reinit(). Will that always be the case? --- Roy ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |