While you have been jabbering away I have fixed the problem. We didn't manage the initialization process properly when the user created CUSP vectors but did not do something to them before using them in things like VecView(). Please let me know if the problem is not resolved or if new problems appear. The initialization business is simplier now also.
PETSc has always and will always initialize vectors and matrix to 0 upon creation. There are too many difficulties with users not zeroing that it is not worth the (tiny) advantage of delaying/avoiding the zeroing. With regard to Jed's concern about first touch etc the answer is that PETSc STANDARD (non-pthread) vectors are not intended for use with threads and so there would be no reason to allow the user (as if they could) do proper locality stuff. The pthread versions of the vectors will automatically do the right locality stuff when zeroing so you get the good behavior (they may already do it right?). Unless one has other concerns on the issue this topic is now closed for discussion :-) Barry On Nov 9, 2011, at 2:01 PM, Jed Brown wrote: > On Wed, Nov 9, 2011 at 13:58, Lisandro Dalcin <dalcinl at gmail.com> wrote: > What tactic? Leave entries uninitialized? I'm just asking for PETSc to > behave consistently. If CPU memory is zeroed when Vecs are created, > the same should happen for GPU memory. > > I agree that it should be consistent between the CPU and GPU. I could go > either way as to whether the default state was initialized or uninitialized, > but I think uninitialized should be available somehow and we should check > that the library behaves correctly in that case.
