Have a look at the list of changes - it is currently here
https://urldefense.us/v3/__https://petsc.org/main/changes/dev/__;!!G_uCfscf7eWS!ZGeiat-1aoVqZo1IPI1kAEiFCl1GTP4Z65w0m3KJrZCopfOFNwbrmOPmjLGwC4J7Tw79C-8ozaNsXI05qkXz8Y18$
until the new version is released. See the last section "Fortran".
The functions ending in "F90" have been renamed, just remove the "F90" suffix.
Regarding the info-related errors, a workaround is to append %v, for instance
mal = info(MAT_INFO_MALLOCS%v)
But Barry may want to provide a better fix for this.
Jose
> El 23 mar 2025, a las 8:42, Jose E. Roman via petsc-users
> <[email protected]> escribió:
>
> The Fortran interfaces for those functions are generated correctly, see
> $PETSC_ARCH/ftn/mat/petscmat.h90
>
> For instance:
>
> interface MatMPIBAIJSetPreallocation
> subroutine MatMPIBAIJSetPreallocation(a,b,c,d,e,f, z)
> import tMat
> Mat :: a
> PetscInt :: b
> PetscInt :: c
> PetscInt :: d(*)
> PetscInt :: e
> PetscInt :: f(*)
> PetscErrorCode z
> end subroutine
> end interface
>
> The compiler message is probably due to the type of an argument not matching
> the expected one. In particular, if you are passing NULL in one of the array
> arguments, you should use PETSC_NULL_INTEGER_ARRAY and not PETSC_NULL_INTEGER.
>
> Jose
>
>
>> El 23 mar 2025, a las 8:25, Sanjay Govindjee via petsc-users
>> <[email protected]> escribió:
>>
>> 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
>>>>> <[email protected]> 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>
>>>>
>>>
>>
>
