Hello,
Thank you all for your suggestions. It seems that the problem arose from setting the NEKTAR_USE_SYSTEM_BLAS_LAPACK option OFF and building ThirdParty lapack. I used a lapack installation which was already provided in the cluster for which I had to specify the path in the FINDNATIVE_BLAS cmake file ( I was under the impression that path was sourced in the bashrc file and that would suffice; which, as it turned out, was not the case).  I also used intel compilers instead of gcc since I was using INTELMPI.


regards,
Nitish

 

 

On Fri, Nov 2, 2018 at 2:02 AM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:
Hi Nitish,

As Fatih has said, this seems to be a problem with linking to the BLAS/Lapack libraries.

If you're using Intel MPI and also have access to Intel compilers and MKL, I would think it is probably advisable to use them over gcc.

However, there's one other thing you can check/try. A situation was reported on the mailing list a couple of weeks ago where linking of libLibUtilities fails with undefined symbols from blas/lapack when you are using ThirdParty blas/lapack and the NEKTAR_USE_SYSTEM_BLAS_LAPACK parameter is set to OFF.

Can you check what values you have set for THIRDPARTY_BUILD_BLAS_LAPACK and NEKTAR_USE_SYSTEM_BLAS_LAPACK in your CMake configuration.

If they're not both set to on, ensure that you have THIRDPARTY_BUILD_BLAS_LAPACK=ON and NEKTAR_USE_SYSTEM_BLAS_LAPACK=ON in your CMake configuration and try building again.

Cheers,
Jeremy

On 1 Nov 2018, at 16:06, Fatih Ertinaz <fertinaz@gmail.com> wrote:

Nitish

That means your linking to BLAS wasn't properly done. Did you check "cmake/FindNativeBlasLapack.cmake" file? 

Also in my opinion, it's not a good idea to mix Intel MPI with GCC unless there is a good reason. If you want to use Intel MPI, I'd use Intel compilers and MKL. 

// Fatih

On Thu, Nov 1, 2018 at 11:43 AM Nitish Arya <nitiesharya@gmail.com> wrote:
Hi Jeremy
I compiled as you suggested with the exact versions of the dependencies in the ThirdParty folder.  But when I did make, the build crashed with the following error.
I am compiling using INTEL MPI and gcc 4.8.5

../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dgemm_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dtpmv_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dgbmv_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dscal_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dgetri_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dgeev_'
../StdRegions/libStdRegions.so.4.4.1: undefined reference to `daxpy_'
../StdRegions/libStdRegions.so.4.4.1: undefined reference to `dcopy_'
../StdRegions/libStdRegions.so.4.4.1: undefined reference to `ddot_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dspmv_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dgemv_'
../LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dsptri_'
collect2: error: ld returned 1 exit status
make[2]: *** [library/UnitTests/UnitTests] Error 1
make[1]: *** [library/UnitTests/CMakeFiles/UnitTests.dir/all] Error 2
make: *** [all] Error 2

Do you have any clues about anything that could trigger this error

regards,
Nitish

On Thu, Nov 1, 2018 at 4:52 AM Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:
Hi Nitish,

In case you haven't yet sorted this out, or it's of use to anyone else, it should be possible to put the third party dependency tarballs into the ${NEKTAR_SRC}/ThirdParty directory and build without the need for any Internet access if you happen to be building on a platform that doesn't have external Internet access.

I've tested a basic Nektar++ build on a fresh Ubuntu 16.04 Linux install where I added only a set of compilers, CMake, gfortran and OpenSSH (Ubuntu packages: build-essential, gfortran, cmake-curses-gui, openssh-server). I then placed the base set of third party dependency tarballs into ${NEKTAR_SRC}/ThirdParty and disconnected the test virtual machine from the network and I was able to successfully configure using ccmake and build Nektar++.

For the Nektar 4.4.1 release source code that I was testing with, I needed to add the following versions of the third party dependencies into ${NEKTAR_SRC}/ThirdParty:

loki-0.1.3.tar.bz2
modmetis-5.1.0_2.tar.bz2
boost_1_57_0.tar.bz2
scotch_6.0.0.tar.gz
tinyxml_2_6_2.tar.gz
zlib-1.2.7.tar.gz


If you're building on some sort of cluster platform that has some of these dependencies in place already then you may not need some of the above tarballs. Likewise, if you're building with MPI which I guess is probably the case, you'll additionally need to add gsmpi-1.2.1_1.tar.bz2  (and of course have an MPI implementation available on the system you're building on). It looks like you also need to manually extract lapack-3.7.0.tar.gz and gsmpi-1.2.1_1.tar.bz2 in ${NEKTAR_SRC}/ThirdParty before you start building.

Unless noted in the list above, you should be able to get the dependencies from https://www.nektar.info/thirdparty/.

If you're configuring via the ccmake text UI rather than using plain cmake, you'll possibly see a number of Boost-related warnings each time you configure but as long as there are no errors, this shouldn't affect the build process.

Jeremy

On 30 Oct 2018, at 14:04, Nitish Arya <nitiesharya@gmail.com> wrote:

Dear Amitvikram,

Thank you for your response. I already disabled the third party build options and kept the tarballs of all the dependencies in the ThirdParty folder as you have mentioned. The problem is that the installer tries to connect to the internet and I think my system curl is not allowing it; at that point, the installation crashes down. I am manually disabling the connect options from all the individual makefiles. I have made through some part of the installation and I hope I will get it done soon. Thank you for your support.


Sincerely,
Nitish

On Tue, Oct 30, 2018 at 7:09 PM Amitvikram Dutta <amitvdutta23@gmail.com> wrote:
Hi Nitish,
Did you turn off the BUILD_THIRDPARTY options on the ccmake screen?
I had a similar problem. I placed a ThirdParty folder containing the tarballs of all the thirdparty dependencies in the NEKTAR_SRC directory (which contains the build dir) and turned off the options that I mentioned above. That worked for me.

Sincerely,

On Tue, Oct 30, 2018 at 9:23 AM Amitvikram Dutta <amitvikram.dutta@uwaterloo.ca> wrote:
 
From: nektar-users-bounces@imperial.ac.ukOn Behalf OfNitish Arya
Sent: October 30, 2018 8:21:04 AM (UTC-05:00) Eastern Time (US & Canada)
To: nektar-users@imperial.ac.uk
Subject: [Nektar-users] Nektar++ installation in a cluster

Hello.
 
I am planning to use APE solver included in the nektar framework. I have to configure the MPI using Intel MPI which is available in the cluster, while dependencies are installed using an internet connection. The internet connection is only available at the head node in which I am unable to invoke the Intel MPI. So it means that I have to compile the dependencies separately. I tried compiling the ThirdParty dependencies separately but when I compiled Nektar, it was again searching for the dependencies via http or https ( both of the protocols are also not working ).

Is there any way I can install Nektar without the installer searching for the dependencies in the internet.


Sincerely,
Nitish
--

Amitvikram Dutta

Graduate Research Assistant

Fluid Mechanics Research Lab

Multi-Physics Interaction Lab

University of Waterloo

_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users

_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users