Dear Roy, On Wed, 14 Jan 2009, Roy Stogner wrote:
> 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. Okay, I didn't know that. >> 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. What do you mean by "Yeah"? Would you like me to do something (NumericVector, PetscVector), or do you mean you will do everything yourselves? In any case, is there any idea about when this will be usable? Best Regards, Tim -- Dr. Tim Kroeger [email protected] Phone +49-421-218-7710 [email protected] Fax +49-421-218-4236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany ------------------------------------------------------------------------------ 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
