[petsc-users] VecValid

Barry Smith bsmith at mcs.anl.gov
Thu May 3 21:53:06 CDT 2012


On May 3, 2012, at 9:39 PM, Blaise Bourdin wrote:

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

   You actually use the type(Mat) A   stuff? Wow? You really have a Fortran fetish.

    Try A%v = 0 at declaration and if (A%v == 0) at check

   Barry



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



More information about the petsc-users mailing list