On 04/23/2015 07:38 PM, Barry Smith wrote:
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
Great, it's not collective. I'll check this out.
Anton
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
