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>