[petsc-users] VecValid

[Blaise Bourdin]

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