Re: [Nektar-users] FW: Nektar++ installation in a cluster
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
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
Hi Nitish, In my case, changing the gcc from 4.8.1 to a higher version also stopped attempts by the compiler to connect. You could try this as an easy fix before going through the makefiles. Good luck! On Tue, Oct 30, 2018 at 10:04 AM 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
--
*Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo
That might be one of the issues. I am using gcc 4.8.5. Nevertheless, I am trying it manually. Let's see if it works. Thanks On Tue, Oct 30, 2018 at 7:38 PM Amitvikram Dutta <amitvdutta23@gmail.com> wrote:
Hi Nitish,
In my case, changing the gcc from 4.8.1 to a higher version also stopped attempts by the compiler to connect. You could try this as an easy fix before going through the makefiles. Good luck!
On Tue, Oct 30, 2018 at 10:04 AM 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
--
*Amitvikram Dutta*
Graduate Research Assistant
Fluid Mechanics Research Lab
Multi-Physics Interaction Lab
University of Waterloo
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 lapack-3.7.0.tar.gz (from http://www.netlib.org/lapack/lapack-3.7.0.tgz) 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
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
lapack-3.7.0.tar.gz (from http://www.netlib.org/lapack/lapack-3.7.0.tgz)
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
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
lapack-3.7.0.tar.gz (from http://www.netlib.org/lapack/lapack-3.7.0.tgz)
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
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
lapack-3.7.0.tar.gz (from http://www.netlib.org/lapack/lapack-3.7.0.tgz)
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
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
lapack-3.7.0.tar.gz (from http://www.netlib.org/lapack/lapack-3.7.0.tgz)
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
participants (4)
- 
                
                Amitvikram Dutta
- 
                
                Fatih Ertinaz
- 
                
                Jeremy Cohen
- 
                
                Nitish Arya