On Wed, 14 Jan 2009, Tim Kroeger wrote: > I don't think that the (serial) grid itself is the decisive thing in > my application. (I watched the memory consumption, and it remains > small during the grid creation procedure and increases drastically > when the systems are created and initialized.)
Keep in mind, the serial mesh isn't the only thing that goes on the SerialMesh. We store our degree of freedom indexing on the Node and Elem objects themselves, and so on a SerialMesh those don't scale well either. And like the current_local_solution, those get allocated and initialized during system initialization. > I think that adding the required functionality to NumericVector and > PetscVector would not be too complicated (PETSc's VecCreateGhost() > seems to do the trick). I can try to do this part myself, that is to > add a constructor that aditionally takes a list of ghost indices that > we want to store (and implement everything on the PETSc side). The > other side is to make the System class use that new constructor (in > PETSc case at least) and, in particular, determine which indices are > actually required. And to do the correct thing when the grid is > refined/coarsened. I feel not able to implement that part because I'm > not familiar enough with the interna of libMesh. Yeah, I can do that easily enough. Ben's already done the hard work of properly creating the "send_list" of ghost DoFs; I don't think I'll have any problem figuring out when to plug that into a constructor or reinitialization function. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
