[petsc-users] VecGet/RestoreArray and related functions

[Barry Smith]

On Dec 1, 2011, at 4:48 PM, Mohammad Mirzadeh wrote:

> Hi guys,
> 
> I am having a conceptual problem trying to design my vector wrappers for my application. The problem is some of vector functionality in PETSc require extra function calls which makes it hard to design a good wrapper. One example that I encountered was when trying to write the destructor for my vector object. You see, for example, the following code is not good enough
> 
> Vector::~Vector(){
> VecDestroy(v_local);
> }
> 
> This, in itself wont work since all calls to VecDestroy() should be made before PetscFinalize() and this wont happen if you define a Vector in your main function since the destructor is called upon exit ... So, I had to fix this by actually having a destructor function memer that I could call explicitly before PetscFinalize() or create the Vector object on the heap so that I can manually invoke the destructor via delete operator!
> 
> Another example I'm struggling with is the following: I am trying to write accessors so that I can do the following:
> 
> Vector a (PETSC_COMM_WORLD, PETSC_DECIDE,10); // make a petsc vector of global length 10 using my own wrappers
> for (int i=0; i<a.GetLocalSize(); i++){
> a(i) = i;
> }
> 
> For this to work, I am using the VecGetArray() and VecRestoreArray() functions. The problem is you cannot easily use them inside the accessor which basically looks something like:
> 
> inline double& Vector::operator()(int i){
> return ptr_to_dataArray[i];
> }

   You are really missing the purpose of the entire get/restore  (and assembly) paradigm in PETSc. The idea is that the user cannot and should not be able to willy-nilly access/change data that is inside a PETSc object. They can/should only do it in a well controlled way (time and place) and that is between the get/restore calls. Yes you can "cheat" by "secretly keeping access to the underlying pointer the entire time but that is dangerous and could result in unexplained crashes or wrong answers when someone changes things at a point in the code they shouldn't.  

    You could overload the square brackets in a[i] to get the array, do what is needed and then restore the array all in the one overload call. That is the only save way to do it.

Barry



> 
> since you need to call to VecRestoreArray after the assignment which means after return!. The simple fix to this is to call the VecGetArray() and VecRestoreArray() in the main function where you are putting in the values but this does not look very neat to me ... so I ended up putting the VecGetArray() inside the constructor and VecRestoreArray() inside the destructor to automate the process. 
> 
> Now I have the following two questions. 1) Is this safe? As far as I could understand from the manual, VecGetArray() "returns" a pointer to internal data stored on this processor. Then I guess VecRestoreArray() is there to somehow nullify the pointer to prevent accidental use of pointer? Since all pointers all private members of my class I assume this is safe then unless these two functions are actually doing some extra work?
> 
> 2) Is there any better way of writing these wrappers and get around the problem of having to call "supplemental" functions safely?
> 
> Sorry if my lack of knowledge is causing all these confusion. 
> 
> Thanks,
> Mohammad
> 
>