[petsc-users] upgrading to 3.22.4

Sanjay Govindjee s_g at berkeley.edu
Sun Mar 23 02:25:16 CDT 2025


Small update.  I managed to eliminate all the errors associated with 
PetscViewer and below (it had to do with the fact that I had not yet 
built a module that was needed).  The errors related to the 
preallocation routines still persists.
-sanjay

On 3/23/25 12:19 AM, Sanjay Govindjee wrote:
> Hi Barry,
>   I have moved to main and rebuilt the PETSc libraries etc.  Right now 
> I am having trouble just getting my source code to compile. Plenty of 
> subroutines with PETSc calls compile but a few are throwing errors and 
> killing my compile. I suspect there will be more but if I can figure 
> these hopefully I can debug the ones that will follow.
> -sanjay
>
>     Error: There is no specific subroutine for the generic
>     'matmpibaijsetpreallocation' at (1)
>     upremas.F:68:72:
>
>        68 |      &                               ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'matseqbaijsetpreallocation' at (1)
>     upremas.F:74:72:
>
>        74 |      &                             ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'matmpiaijsetpreallocation' at (1)
>     upremas.F:77:72:
>
>        77 |      &                             ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'matseqaijsetpreallocation' at (1)
>
>     parkv.F:58:25:
>
>        58 |       PetscViewer    Y_view
>           |                         1
>     Error: Type name 'tpetscviewer' at (1) is ambiguous
>     parkv.F:69:9:
>
>        69 |       endif
>           |         1
>     Error: Expecting END SUBROUTINE statement at (1)
>     parkv.F:72:9:
>
>        72 |       endif
>           |         1
>     Error: Expecting END SUBROUTINE statement at (1)
>     parkv.F:91:66:
>
>        91 |         call
>     PetscViewerASCIIOpen(PETSC_COMM_WORLD,"yvec.m",Y_view,
>     | 1
>     Error: Symbol 'y_view' at (1) has no IMPLICIT type; did you mean
>     'yvec'?
>     parkv.F:65:72:
>
>        65 |         call VecCreate        (PETSC_COMM_WORLD, xvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic 'veccreate'
>     at (1)
>     parkv.F:67:72:
>
>        67 |         call VecSetFromOptions(xvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecsetfromoptions' at (1)
>     parkv.F:68:72:
>
>        68 |         call VecDuplicate     (xvec, yvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecduplicate' at (1)
>     parkv.F:71:72:
>
>        71 |         call VecDuplicate     (xvec, yvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecduplicate' at (1)
>     parkv.F:85:72:
>
>        85 |       call VecAssemblyBegin(xvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecassemblybegin' at (1)
>     parkv.F:86:72:
>
>        86 |       call VecAssemblyEnd  (xvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecassemblyend' at (1)
>     parkv.F:88:72:
>
>        88 |       call MatMult           (Kmat, xvec, yvec, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic 'matmult'
>     at (1)
>     parkv.F:101:72:
>
>       101 |       call VecGetOwnershipRange(yvec, starti, endi, ierr)
>     | 1
>     Error: There is no specific subroutine for the generic
>     'vecgetownershiprange' at (1)
>
>
> -
>
> On 3/21/25 7:17 AM, Barry Smith wrote:
>>
>>     I have just pushed a major update to the Fortran interface to the 
>> main PETSc git branch. Could you please try to work with main (to 
>> become release in a couple of weeks) with your Fortran code as we 
>> debug the problem? This will save you a lot of work and hopefully 
>> make the debugging more straightforward.
>>
>>     You can send the same output with the debugger if it crashes in 
>> the main branch and I can try to track down what is going wrong.
>>
>>   Barry
>>
>>
>>
>>
>>> On Mar 21, 2025, at 12:37 AM, Sanjay Govindjee via petsc-users 
>>> <petsc-users at mcs.anl.gov> wrote:
>>>
>>> I am trying to upgrade my code to PETSc 3.22.4 (the code was last 
>>> updated to 3.19.4 or perhaps 3.18.1, I've lost track). I've been 
>>> using this code with PETSc for over 20 years.
>>>
>>> To get my code to compile and link during this update, I only need 
>>> to make two changes; one was to use PetscViewerPushFormat instead of 
>>> PetscViewerSetFormat and the other was to use 
>>> PETSC_NULL_INTEGER_ARRAY in a spot or two.
>>>
>>> When I run the code however, I am getting an error very early on 
>>> during a call to MatCreate near the beginning of the code.  The 
>>> screen output says:
>>>
>>>     [3]PETSC ERROR: matcreate_() at
>>>     /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101
>>>     Cannot create PETSC_NULL_XXX object
>>>     [0]PETSC ERROR: matcreate_() at
>>>     /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101
>>>     Cannot create PETSC_NULL_XXX object
>>>     [1]PETSC ERROR: matcreate_() at
>>>     /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101
>>>     Cannot create PETSC_NULL_XXX object
>>>     [2]PETSC ERROR: matcreate_() at
>>>     /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101
>>>     Cannot create PETSC_NULL_XXX object
>>>
>>> I have a 4 processor run going.  I am running with 
>>> -on_error_attach_debugger but the debugger is giving me cryptic (at 
>>> least to me) output (the same for all 4 processes modulo the PID).  
>>> Stack traces seem to be unavailable :(
>>>
>>>     lldb  -p 71963
>>>     (lldb) process attach --pid 71963
>>>     Process 71963 stopped
>>>     * thread #1, queue = 'com.apple.main-thread', stop reason =
>>>     signal SIGSTOP
>>>         frame #0: 0x00007fff69d92746
>>>     libsystem_kernel.dylib`__semwait_signal + 10
>>>     libsystem_kernel.dylib`__semwait_signal:
>>>     ->  0x7fff69d92746 <+10>: jae 0x7fff69d92750            ; <+20>
>>>         0x7fff69d92748 <+12>: movq   %rax, %rdi
>>>         0x7fff69d9274b <+15>: jmp 0x7fff69d9121d            ; cerror
>>>         0x7fff69d92750 <+20>: retq
>>>     Target 0: (feap) stopped.
>>>
>>>     Executable module set to "/Users/sg/Feap/ver87/parfeap/feap".
>>>     Architecture set to: x86_64h-apple-macosx-.
>>>
>>> Does anyone have any hints as to what may be going on?  Note the 
>>> program starts normally and i can do stuff with the interactive 
>>> interface for the code -- even plotting the mesh etc. so I believe 
>>> the input data has been read in correctly.  The crash only occurs 
>>> when I initiate the formation of the matrix.
>>>
>>> I am attaching the 
>>> /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c file 
>>> in case that offers some insight.
>>>
>>> Note, I have been
>>> -sanjay
>>> -- 
>>> <gcreatef.c>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20250323/0ac4d387/attachment-0001.html>


More information about the petsc-users mailing list