On Thu, 5 Feb 2009, Tim Kroeger wrote: > (1) In the ghosted version of PetscVector::init(), you have placed an assert > that checks whether the mesh is disjoint. Why is this necessary?
No - it's an assert that checks whether someone's trying to initialize a disjoint ghosted vector, which should never happen unless the mesh is disjoint. If for some reason someone really wants to run a fully coupled system on a disjoint mesh, then they take out the assert. If someone's running on a connected mesh and that assert trips, then it's caught a problem with the code. > (2) In PetscVector::close(), I currently wonder why I used SCATTER_REVERSE in > the call to VecGhostUpdateBegin/End(). This seems to be wrong, it should be > SCATTER_FORWARD instead. Thanks; I'll fix that now. > (3) It so happened that I looked at PetscVector<T>::operator=(const > std::vector<T>& v) and noticed that in the ghosted case, it might be > appropiate to set _is_closed to false. This is because for ghosted vectors, > close() will also update the ghost values automatically. What do you think? Hmmm... we don't want to change _is_closed (requiring the user to close() after operator= would be an API change, which I'd like to avoid as much as possible), but it looks like we need to do *something* within operator= itself - as is it won't be setting the ghosted values at all. > On Wed, 4 Feb 2009, Roy Stogner wrote: > >> There's still something wrong with the localize() called from >> System::update(), but now it's not a bug so much as my failure to >> understand how PETSc is supposed to work: in a simple failing test >> case (the first update() in ex14 run on 2 procs), the index sets >> appear to be built correctly, but the scatter doesn't update >> current_local_solution the way I expect it to. The bug's either in >> localize() or in operator()(), both of which are fairly small simple >> functions but which are based on PETSc APIs I'm not familiar enough >> with. > > Might it be that this was just due to my item (2) above? I don't think so - the failure was either *within* the localize function (whose results I tested before the function even exited) or within the operator() function (which I used to perform the tests). But let me check... Nope, ex14 gives the same problem even after your close() fix. > Actually, for ghosted vectors, I think localize() isn't required to > be called at all, is it? Baby steps, baby steps. Right now we've turned current_local_solution and kin from serial vectors into ghosted vectors, but for that to work properly we need correct behavior from solution->localize(current_local_solution, send_list) Eventually, we'll get rid of current_local_solution entirely and just use ghosted vectors everywhere we use parallel vectors now... but that's too big a change to make in one jump without testing, and it's a change I don't want to make at all until our EpetraVector interface (and preferably our DistributedVector, but that can wait) supports it. --- Roy ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
