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.
