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
>
> -----------------------------------------------
>
