[petsc-users] VecGet/RestoreArray and related functions

[Mohammad Mirzadeh]

Thank you Barry. I agree that what I did disregards the safety measures in
PETSc but I figured that's the only way I could make it look more like
normal std::vector.

Chetan: That's an interesting trick! Thanks.

Thanks again guys

On Thu, Dec 1, 2011 at 3:10 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20111201/349256ac/attachment.htm>