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