> On Apr 23, 2015, at 8:41 AM, anton <[email protected]> wrote: > > > On 04/23/2015 01:36 PM, Matthew Knepley wrote: >> On Thu, Apr 23, 2015 at 6:28 AM, anton <[email protected]> wrote: >> Hi, >> >> I'm currently calling DMDAVecGet(Restore)Array on a subset of processors. It >> seems to work correctly. So why does documentation say they are collective >> on Vec? Are they really? Unlike VecNorm, for example, it's not really clear >> why DMDAVecGetArray should be collective. >> >> The documentation should be fixed. Its "logically collective" just like >> VecGetArray(), and unlike VecGetArrayRead(). >> >> Am I still on a safe side, or I'm seriously violating something that's not >> immediately obvious. >> >> You are violating something that is not obvious. GetArray() will increment >> the status marker on the Vec since you >> could have changed something, but then you will get inconsistency across >> processes in this marker, so you could >> make different decisions about whether to recompute norms, etc. Hard to >> debug errors. >> > > OK, thanks Matt, I'll simply add dummy calls on those processes where I don't > need the data.
If you are only "reading" information from the array you should switch to the DMDAVecGetArrayRead() versions available in the development version of PETSc, then you do not need to call on all processes. Barry > > Anton > >> Thanks, >> >> Matt >> >> Thanks, >> Anton >> >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener >
