The errors are strange. The traceback points to harmless operations. Likely memory corruption, as the message says.
Those tests are included in SLEPc pipelines, they are run with serveral Linux distributions, with several compilers. Also, on my macOS it runs cleanly, although my configuration is different from yours. I don't have access to an M1 computer. Also, using gcc instead of clang from xcode may have unexpected side effects, I don't know. I would try with less agressive optimization flags, e.g., --COPTFLAGS=-O --CXXOPTFLAGS=-O --FOPTFLAGS=-O (or even remove them completely). Maybe try also --with-debugging=0. Another thing you can try is change the BLAS/LAPACK, e.g., removing --download-fblaslapack or replace it with --download-netlib-lapack See also the FAQ https://petsc.org/release/faq/#what-does-corrupt-argument-or-caught-signal-or-segv-or-segmentation-violation-or-bus-error-mean-can-i-use-valgrind-or-cuda-memcheck-to-debug-memory-corruption-issues Jose > El 20 dic 2023, a las 22:19, Kenneth C Hall <kenneth.c.h...@duke.edu> > escribió: > > Jose, > > I have been revisiting the issue of SLEPc/NEP for shell matrices T(lambda) > and T'(lambda). > I am having problems running SLEPc/NEP with -nep_type nleigs. > > I have compiled two versions of PETSc/SLEPc: > > petsc-arch-real / slepc-arch-real > ./configure --with-cc=gcc-13 --with-cxx=g++-13 --with-fc=gfortran > --COPTFLAGS='-O3 -fopenmp' --CXXOPTFLAGS='-O3 -fopenmp' > --FOPTFLAGS='-O3 -fopenmp' --with-debugging=1 > --with-logging=1 --with-scalar-type=real --with-precision=double > --download-fblaslapack --with-openmp --with-mpi=0 > > > petsc-arch-complex / slepc-arch-complex > ./configure --with-cc=gcc-13 --with-cxx=g++-13 --with-fc=gfortran > --COPTFLAGS='-O3 -fopenmp' --CXXOPTFLAGS='-O3 -fopenmp' > --FOPTFLAGS='-O3 -fopenmp' --with-debugging=1 > --with-logging=1 --with-scalar-type=complex --with-precision=double > --download-fblaslapack --with-openmp --with-mpi=0 > > I use gfortran on an Apple Mac Mini M1. Both the PETSc and SLEPc versions > are the latest development versions as of today (a6690fd8 and 267bd1cd, > respectively). > > I ran the ex54f90 test cases: > > % main-arch-real -nep_type slp -nep_slp_ksp_type gmres > -nep_slp_pc_type none > % main-arch-complex -nep_type slp -nep_slp_ksp_type gmres > -nep_slp_pc_type none > % main-arch-real -nep_type nleigs -rg_interval_endpoints 0.2,1.1 > -nep_nleigs_ksp_type gmres -nep_nleigs_pc_type none > % main-arch-complex -nep_type nleigs -rg_interval_endpoints > 0.2,1.1,-.1,.1 -nep_nleigs_ksp_type gmres -nep_nleigs_pc_type none > > Both the slp cases ran as expected and gave the correct answer. > However, both the real and complex architectures failed for the nleigs case. > > For the complex case, none of the callback functions appear to have been > called. > For the real case, only the MatMult_A routine appears to be called, 100 times > and returns each time, sweeping over lambda from 0.2 to 1.1. > > Any suggestions would be welcome. > > Best regards, > Kenneth Hall >