On Wed, 1 Sep 2010, Derek Gaston wrote:
> On Aug 31, 2010, at 2:36 PM, Roy Stogner wrote: > >> The effect you want should be to add a get_send_list() argument and >> change PARALLEL to GHOSTED in system.C lines 230, 246, 262, 310, 593. >> Try that first and see if it works. If it turns out to be what you >> need, then we could add it as an option to the library; maybe create a >> new System::init_parallel_vector() method that gets called on those >> lines and either inits a PARALLEL by default or a GHOSTED if some >> System::all_ghosted_vectors boolean is true? > > Ok - I made these changes... and everything works for me. I'm going > to take your suggestion and implement init_parallel_vector().... > with the bool you suggested unless someone has objections. I'm not sure I understood Jed's suggestion - eliminate parallel non-ghosted vectors entirely, then write our own ghosting support to handle the non-PETSc backends? That seems like a lot of work to get slightly more robust support for a feature that most people wouldn't need. We already support non-ghosted vectors, we already support ghosted vectors (efficiently with PETSc or inefficiently otherwise), why not just let people choose between them even for the "internal" vectors? My single-bool suggestion isn't the best way to do things. Ideally any time we're reinitializing an existing vector (lines 246, 262, 310) we want to query it and reinitialize it with the same type it already had. We could use a bool (or better, an enum ParallelType) to determine how to initialize everything - perhaps a System member for System::solution and as another optional argument to System::add_vector() for others. But you've been sounding like you're in a hurry; if you want to start with the single-bool now and get things just right after whatever deadline is past, that's fine too. --- Roy ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
