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