[petsc-users] a subtle usage of Vec

[Barry Smith]

On May 21, 2010, at 10:37 AM, SUN Chun wrote:

> Hi PETSc developers,
> 
> 
> I know this might be not good but I just want to hear confirmation from you guys. I'm creating Vec with arrays (both SEQ and MPI) which I allocate myself. However, I'm keeping the pointer, and later on whenever I want to change that vector's values, instead of calling VecSetValues, I just use my pointer and directly access it. And feeling guilty afterwards, I call VecAssembly even though I know it should do nothing. So far this hasn't produce any problem to me but I'm afraid it will do so. Would you please confirm that this usage is acceptable or not? If not acceptable, what's the potential threat?
> 
   You DO NEED to call the VecAssembly. Make sure you call that after every time you change values. Then I think it should be ok.

> The reason is the following: In the same code, I have a KSP object which I keep using with multiple solves. At some point, I'm getting a -8, which is fine. What is not fine is, if I delete this KSP object, create a new one, re-setup from options, I got convergence. But setting the same bunch of these options on the old KSP object still gives me -8. I'm suspecting memory corruption at some level, but all I can suspect is the Vec usage.

   Run with valgrind to check for memory corruption http://www.mcs.anl.gov/petsc/petsc-as/documentation/faq.html#valgrind

   During the KSP solve you do not know which vectors are being used so you shouldn't be changing values directly in your array. (For example in a MatMult() or PCApply() if you are using a matshell or pcshell).


   Barry

> 
> 
> Thanks a lot,
> Chun
> 
> 
> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.  If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.