It turned out to be another third-party library that had some functions names same as those from BLAS. This was confusing LAPACK. Building without that library is leading to expected results from the code.
What I don’t understand is why this shows up on one platform out of the four different OSs that I have been using this code on. -Manav > On Apr 8, 2017, at 2:20 AM, Satish Balay <[email protected]> wrote: > > I would do a minimal petsc build - without any packages from > /usr/local - and see if the problem presists.. > > Satish > > On Fri, 7 Apr 2017, Barry Smith wrote: > >> >>> On Apr 7, 2017, at 3:34 PM, Manav Bhatia <[email protected]> wrote: >>> >>> Yes, I printed the data in both cases and they look the same. >>> >>> I also used “set step-mode on” to show the system lapack info, and they >>> both are using the same lapack routine. >>> >>> This is still baffling me. >> >> alignment of the input arrays, both the same? >> >> I don't know why this is happening; what if you use your standalone code >> but link against all the libraries that are linked against for the PETSc >> case. >> >> >> >> >>> >>> -Manav >>> >>> >>>> On Apr 7, 2017, at 3:22 PM, Barry Smith <[email protected]> wrote: >>>> >>>> >>>>> On Apr 7, 2017, at 2:57 PM, Manav Bhatia <[email protected]> wrote: >>>>> >>>>> Hi Barry, >>>>> >>>>> Thanks for the inputs. >>>>> >>>>> I did try that, but the debugger (gdb) stepped right over the dgeev_ >>>>> call, without getting inside the function. >>>> >>>> Did it at least stop at the function so you do an up and print all the >>>> arguments passed in? >>>> >>>>> >>>>> I am wondering if this has anything to do with the fact that the system >>>>> lapack library might not have any debugging info in it. >>>> >>>> Yeah I forgot it might not have them. >>>> >>>> Barry >>>> >>>>> >>>>> Thoughts? >>>>> >>>>> Regards, >>>>> Manav >>>>> >>>>>> On Apr 7, 2017, at 2:40 PM, Barry Smith <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Apr 7, 2017, at 1:46 PM, Manav Bhatia <[email protected]> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have compile petsc on my Ubuntu machine (also Mac OS 10.12 >>>>>>> separately) to link to the system lapack and blas libraries (shown >>>>>>> below). >>>>>>> >>>>>>> I have created an interface class to dgeev in lapack to calculate the >>>>>>> eigenvalues of a matrix. >>>>>>> >>>>>>> My application code links to multiple libraries: libMesh, petsc, slepc, >>>>>>> hdf5, etc. >>>>>>> >>>>>>> If I test my interface inside this application code, I get junk >>>>>>> results. >>>>>> >>>>>> This is easy to debug because you have a version that works. >>>>>> >>>>>> Run both versions in separate windows each in a debugger and put a break >>>>>> point in the dgeev_ function. When it gets there check that it is the >>>>>> same dgeev_ function in both cases and check that the inputs are the >>>>>> same then step through both to see when things start to change between >>>>>> the two. >>>>>> >>>>>>> >>>>>>> However, on the same machine, if I use the interface in a separate >>>>>>> main() function without linking to any of the libraries except lapack >>>>>>> and blas, then I get expected results. >>>>>>> >>>>>>> Also, this problem does not show up on Mac. >>>>>>> >>>>>>> I am not sure what could be causing this and don’t quite know where to >>>>>>> start. Could Petsc have anything to do with this? >>>>>>> >>>>>>> Any insight would be greatly appreciated. >>>>>>> >>>>>>> Regards, >>>>>>> Manav >>>>>>> >>>>>>> manav@manav1:~/test$ ldd /opt/local/lib/libpetsc.so >>>>>>> linux-vdso.so.1 => (0x00007fff3e7a8000) >>>>>>> libsuperlu_dist.so.5 => /opt/local/lib/libsuperlu_dist.so.5 >>>>>>> (0x00007f721fbd1000) >>>>>>> libparmetis.so => /opt/local/lib/libparmetis.so >>>>>>> (0x00007f721f990000) >>>>>>> libmetis.so => /opt/local/lib/libmetis.so (0x00007f721f718000) >>>>>>> libsuperlu.so.5 => /opt/local/lib/libsuperlu.so.5 >>>>>>> (0x00007f721f4a7000) >>>>>>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >>>>>>> (0x00007f721f124000) >>>>>>> liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f721e92c000) >>>>>>> libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f721e6bd000) >>>>>>> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 >>>>>>> (0x00007f721e382000) >>>>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 >>>>>>> (0x00007f721e079000) >>>>>>> libmpi_mpifh.so.12 => /usr/lib/libmpi_mpifh.so.12 >>>>>>> (0x00007f721de20000) >>>>>>> libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 >>>>>>> (0x00007f721daf4000) >>>>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 >>>>>>> (0x00007f721d8f0000) >>>>>>> libmpi.so.12 => /usr/lib/libmpi.so.12 (0x00007f721d61a000) >>>>>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 >>>>>>> (0x00007f721d403000) >>>>>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >>>>>>> (0x00007f721d1e6000) >>>>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 >>>>>>> (0x00007f721ce1d000) >>>>>>> /lib64/ld-linux-x86-64.so.2 (0x000055d739f1b000) >>>>>>> libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 >>>>>>> (0x00007f721cbcf000) >>>>>>> libopen-pal.so.13 => /usr/lib/libopen-pal.so.13 >>>>>>> (0x00007f721c932000) >>>>>>> libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 >>>>>>> (0x00007f721c6f2000) >>>>>>> libibverbs.so.1 => /usr/lib/libibverbs.so.1 (0x00007f721c4e3000) >>>>>>> libopen-rte.so.12 => /usr/lib/libopen-rte.so.12 >>>>>>> (0x00007f721c269000) >>>>>>> libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 >>>>>>> (0x00007f721c064000) >>>>>>> libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 >>>>>>> (0x00007f721be5e000) >>>>>>> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 >>>>>>> (0x00007f721bc56000) >>>>>>> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 >>>>>>> (0x00007f721ba52000) >>>>>>> libhwloc.so.5 => /usr/lib/x86_64-linux-gnu/libhwloc.so.5 >>>>>>> (0x00007f721b818000) >>>>>>> libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 >>>>>>> (0x00007f721b60c000) >>>>>>> libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 >>>>>>> (0x00007f721b402000) >>>>>>> >>>>>> >>>>> >>>> >>> >> >>
