[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Here is a summary of the installation process on Cray XC50. I have configured deal.II with MPI, LAPACK, SCALAPACK, PETSc and p4est. Our system didn't have p4est so I started with installing it. All cray libraries are in /opt/cray/pe/lib64/ in out system. *Installing p4est* 1. Download source fi

Re: [deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Le jeu. 13 févr. 2020 à 07:27, vachan potluri a écrit : > > It is working! > > The mistake I did was to open an interactive job and run the executables > through bash. When I instead submitted a job, and executed using aprun > (Cray's equivalent to mpirun) to run the executables, they ran succes

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

It is working! The mistake I did was to open an interactive job and run the executables through bash. When I instead submitted a job, and executed using aprun (Cray's equivalent to mpirun) to run the executables, they ran successfully. I tested step-1, step-18 and my own code too. The installa

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

I have found few reports of glibc version 2.28 causing such behaviour (e.g. see here ). It might be possible that /lib64/ld-linux-x86-64.so.2 on our system "links" to this version of glibc. But it actually is a static library: $ ldd -v ld-linux-x86-64.so.2

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

This is the full backtrace with gdb. (gdb) bt #0 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/ComptGasDynLab/vachanpotluri/source/dealii-9.1.1/source/numerics/time_dependent.cc:1196 #1 0x7fffec1aa6f8 in _GLOBAL__sub_I_time_dependent.cc(void) ()

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Vachan, On Wednesday, February 12, 2020 at 12:24:38 AM UTC-5, vachan potluri wrote: > > Step-1 aborts with Illegal Instruction (core dumped). The error msg gdb > prints is the following. > Program received signal SIGILL, Illegal instruction. > __static_initialization_and_destruction_0 (__initiali

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Step-1 aborts with Illegal Instruction (core dumped). The error msg gdb prints is the following. Program received signal SIGILL, Illegal instruction. __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/ComptGasDynLab/vachanpotluri/source/dealii-9.1.1/sourc

Re: [deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

On 2/11/20 12:09 AM, vachan potluri wrote: However, make test shows all tests failing with the error /bin/sh: .: command not found. When I navigated to tests/quick_tests and individually ran the tests, the output was as follows. $ ./lapack.debug Illegal instruction Can anyone help me with thi

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Ok. After installing newer cmake version and making _lapack_libraries OPTIONAL, LAPACK configuration has gone fine. For PETSc, I did something dirty. I figured that FindPETSC.cmake searches for libraries in a file named petscvariables. I made my own copy of petscvariables file and modified the

[deal.II] Re: Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

> > If only an old version is the problem, I would just go ahead and download > and compile a recent version myself. I never had any issues with that and > should be quite simple. I did this. Indeed the cmake output now prints A library with LAPACK API found. However, the lapack configuration