Hi, As a side note: this is actually a problem I have met in one of the TS examples. When using fortran datatypes, the statements "A=0" and "if (A .eq. 0)" are not valid. They would require overloading the assignment and comparison operators. Can anybody see an alternative?
Blaise > > 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 >> >> ----------------------------------------------- >> > -- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin