Thanks. I think this will work for us. -sanjay On 5/3/12 7:22 PM, Barry Smith wrote: > VecValid was unsafe because it looks inside a data structure that may or > not be valid. > > In Fortran the safe way to do this is to set the value to 0 right after > declaration and then check if not zero. So > > Mat A > > A = 0 > > ....... > > if (A .eq. 0) then > call VecCreate( A,ierr) > endif > > Barry > > On May 3, 2012, at 9:17 PM, Sanjay Govindjee wrote: > >> The entry points for our code can vary. Thus a vector for example can get >> created in a handful >> of routines. But it is possible that the vector has already been created in >> another routine. So >> we perform a VecValid check on it. If it is false we create it, else we go >> on and use it. Also at >> the end when we exit the program we clean up with a series of VecDestroy >> calls but we check first if the vector is valid before calling VecDestroy on >> it. Same for MatValid/MatDestroy. >> >> Obviously we can store a logical flag in a common block or the like upon >> creation; but VecValid and >> MatValid were handy utility functions for us. >> >> Is is feasible to call PetscValidHeaderSpecific( ) out of fortran? Or >> should should I just set up my own >> collection of allocate/deallocate flags. >> >> -sanjay >> >> On 5/3/12 7:08 PM, Matthew Knepley wrote: >>> On Thu, May 3, 2012 at 9:20 PM, Sanjay Govindjee<s_g at berkeley.edu> >>> wrote: >>> We have some code that has worked up through petsc-3.1 and we are in the >>> process of updating it to petsc-3.2. >>> >>> One thing that I can not find mentioned in the change logs (looking all the >>> way back to petsc-2.1.0) or the FAQs is the elimination of the VecValid and >>> MatValid tests. >>> >>> In C, this is now the macro PetscValidHeaderSpecific(). This check now >>> happens in every function call. What >>> logic would need to look for a corrupt Vec beyond CHKERRQ? >>> >>> Thanks, >>> >>> Matt >>> >>> We used to perform operations like: >>> >>> call VecValid(xvec, chk, ierr) >>> >>> if(chk .eqv. PETSC_FALSE) then >>> call VecCreate (PETSC_COMM_WORLD, xvec, ierr) >>> call VecSetSizes (xvec, numpeq, PETSC_DECIDE, ierr) >>> call VecSetFromOptions(xvec, ierr) >>> else >>> .... >>> endif >>> >>> But it seems VecValid and MatValid have been eliminated. Is there a reason >>> for this? or have >>> I made a mistake? Is there a replacement test for invalid Vec and Mat >>> pointers? >>> >>> -sanjay >>> >>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >> -- >> ----------------------------------------------- >> Sanjay Govindjee, PhD, PE >> Professor of Civil Engineering >> >> 779 Davis Hall >> Structural Engineering, Mechanics and Materials >> Department of Civil Engineering >> University of California >> Berkeley, CA 94720-1710 >> >> Voice: +1 510 642 6060 >> FAX: +1 510 643 5264 >> >> s_g at berkeley.edu >> http://www.ce.berkeley.edu/~sanjay >> >> ----------------------------------------------- >>
-- ----------------------------------------------- Sanjay Govindjee, PhD, PE Professor of Civil Engineering 779 Davis Hall Structural Engineering, Mechanics and Materials Department of Civil Engineering University of California Berkeley, CA 94720-1710 Voice: +1 510 642 6060 FAX: +1 510 643 5264 s_g at berkeley.edu http://www.ce.berkeley.edu/~sanjay -----------------------------------------------
