Matthew Knepley <[email protected]> writes: > I am trying to understand what you are saying here. I have a vector on 2 > procs, divided as > > p0 |----interior---|--ghost--| > > p1 |----interior---|--ghost--|
Remember that the global Vec consists of just the interiors. The local form is a sequential Vec that includes ghosts. > Now I calculate some values in the interior on both procs using > VecGetArray(), > > p0 |xxxxinteriorxxx|--ghost--| > > p1 |xxxxinteriorxxx|--ghost--| If you do it this way, then the global Vec is complete without needing to communicate anything. > What is wrong with calling VecGhostUpdate() here to fill in the > ghosts? The ghost values aren't part of the global Vec, so it's just needless communication. But more insidiously, it encourages an interface where the input Vec is assumed to have updated ghost values (a "hidden" property). > Is your contention that I should have also calculated the ghosts? No. But if you have a FE discretization then you're presumably using ADD_VALUES. With VecGhost, the natural thing is to put your entries in the local form and use VecGhostUpdate(x,ADD_VALUES,SCATTER_REVERSE). Note that you would need a subsequent VecGhostUpdate(x,INSERT_VALUES,SCATTER_FORWARD) if you wanted the local form to be consistent with the now-assembled global form. But the algebraic solvers don't need that, so it's only relevant if user code will be called on that Vec prior to modification of any type by the algebraic solver, and having user code assume the ghost values are current is a dangerous assumption that will make your code fragile and disgusting.
signature.asc
Description: PGP signature
