Hi all, I had to use a slight workaround because the platform I was compiling on could not download the thirdparty files correctly and would always give a hash mismatched error. I downloaded the third party files on my home machine and re-uploaded them into the $NEKTAR_HOME folder. As a result when I begin the build process the ThirdParty folder is populated with the zipped versions of the third party software. Is this what what might be causing the problem? Is there any way to edit the cmake file and to get the compilation process working correctly? On Fri, Oct 12, 2018 at 2:57 PM Amitvikram Dutta < amitvikram.dutta@uwaterloo.ca> wrote:
*From:* nektar-users-bounces@imperial.ac.ukOn Behalf OfJeremy Cohen *Sent:* October 12, 2018 2:56:43 PM (UTC-05:00) Eastern Time (US & Canada)
*To:* Amitvikram Dutta *Cc:* nektar-users *Subject:* Re: [Nektar-users] Problem while installing nektar++ with lapack
Hi Amitvikram,
Have you attempted to build lapack separately at any point? It's probably worth clearing out your build directory and also all the contents of the ThirdParty directory in the base nektar++ source directory, which I'll call $NEKTAR_HOME, so $NEKTAR_HOME/ThirdParty and then re-running cmake in an empty $NEKTAR_HOME/build directory and trying the build again.
It looks like the build step is encountering a previous source tree in the location where it's trying to build which seems strange.
I've just had a look at the log from my clean build and I see exactly the same messages as you in relation to lapack-3.7.0 in the same order as far as "Checking whether /usr/bin/f95 supports Fortran 90 -- yes", however, I then see "-- Looking for Python greater than 2.6 - " and the build of lapack completes successfully.
Just to confirm, I am running cmake and make in a separate build directory under the main nektar++ source tree directory, so I'm building in $NEKTAR_HOME/build - I assume you're doing something similar? You should see a ThirdParty directory in $NEKTAR_HOME and another ThirdParty directory in $NEKTAR_HOME/build/
I believe that the initial download of the lapack-3.7.0.tar.gz should be placed in $NEKTAR_HOME/ThirdParty and unpacked there. Then, when the build succeeds or stops, in $NEKTAR_HOME/build/ThirdParty, you should see lapack-3.7.0/ where I think the build actually takes place, and then a separate $NEKTAR_HOME/build/ThirdParty/lapack-3.7.0-tmp which should contain a couple of lapack-3.7.0-cfgcmd.txt files that I think contain the build command that is used - you could perhaps paste the contents of the lapack-3.7.0-cfgcmd.txt into an email if you're still having issues and we can see if that looks correct.
It is, of course, possible that this is something related to the specific configuration of the platform that you're building on, but I think the third party lapack build should be straightforward and it sounds like for some reason, it's attempting to build in the wrong location, or a location where an existing source tree has ended up for some reason.
I'm afraid I don't have a very detailed knowledge of the build system beyond this so if none of the suggestions so far help you to resolve the problem, maybe someone with more knowledge of the build system can provide some advice.
Cheers, Jeremy
On 12 Oct 2018, at 19:34, Amitvikram Dutta <amitvdutta23@gmail.com> wrote:
Hi all,
I tried to compile nektar using Jeremy's latest suggestions having both THIRDPARTY_BUILD_BLAS_LAPACK and NEKTAR_USE_SYSTEM_BLAS_LAPACK turned on. The following error occured. It seems that I might have to compile lapack separately. Is this unusual?
<image.png>
On Fri, Oct 12, 2018 at 1:16 PM Amitvikram Dutta < amitvikram.dutta@uwaterloo.ca> wrote:
*From:* nektar-users-bounces@imperial.ac.ukOn Behalf OfJeremy Cohen *Sent:* October 12, 2018 1:16:14 PM (UTC-05:00) Eastern Time (US & Canada)
*To:* Amitvikram Dutta *Cc:* nektar-users *Subject:* Re: [Nektar-users] Problem while installing nektar++ with lapack
Hi Amitvikram,
As Chris suggests, it's probably better to use vendor supplied libraries if you can get those working.
In addition to the further information Chris has asked to take a look at, one thing you could check is to whether there are any files in your nektar++/build/ThirdParty/lapack-3.7.0 directory (if that directory exists at all).
I've been trying to see if I can recreate the problem and I was able to see something similar when setting THIRDPARTY_BUILD_BLAS_LAPACK=ON and NEKTAR_USE_SYSTEM_BLAS_LAPACK=OFF. In this case, I can configure successfully and start the build but it fails with a large number of undefined references that are similar to, and include, the dtpmv_ symbol that you mentioned. When I look in nektar++/build/ThirdParty/lapack-3.7.0, the directory is empty so it looks like the build system has configured on the basis of building its own blas/lapack but the build hasn't been carried out and therefore LibUtilities can't be linked against it.
As a test, you could try running the build with both THIRDPARTY_BUILD_BLAS_LAPACK=ON and NEKTAR_USE_SYSTEM_BLAS_LAPACK=ON, if this isn't the setting you've been using already. When I tried this, the build of blas/lapack is carried out successfully and the linking is fine with the full build of Nektar++ completing successfully. I removed the system blas/lapack on my test system to be sure it was linking against the correct instance.
Cheers, Jeremy
On 12 Oct 2018, at 17:50, Chris Cantwell <c.cantwell@imperial.ac.uk> wrote:
Hi Amitvikram,
Could you send us your CMakeCache.txt file from your build directory and the output from running: make VERBOSE=1 for both cases.
In the case of using ThirdParty LAPACK, it seems to not be linking to it. Probably you should be using vendor-supplied libraries if possible though so better if ee can get those working.
Thanks, Chris
On 12 October 2018 14:08:55 BST, Amitvikram Dutta <amitvdutta23@gmail.com> wrote:
Hi Jeremy,
I'm actually trying to build nektar++ on a BGQ cluster similar to Mira.
I'm trying to build nektar++-4.4.1 and the system lapacek version is 3.4.2
Sincerely, On Fri, Oct 12, 2018 at 4:24 AM Amitvikram Dutta < amitvikram.dutta@uwaterloo.ca> wrote:
------------------------------ *From:* nektar-users-bounces@imperial.ac.ukOn Behalf OfJeremy Cohen *Sent:* October 12, 2018 4:24:33 AM (UTC-05:00) Eastern Time (US & Canada) *To:* Amitvikram Dutta *Cc:* nektar-users *Subject:* Re: [Nektar-users] Problem while installing nektar++ with lapack
Hi Amitvikram,
Can you provide some further details of the problem you're encountering.
Specifically, can you confirm what platform (including version) you're building on, and if Linux, which I assume is the platform you're using, which distribution.
Can you also confirm what version of Nektar++ you're trying to build, and the version of the system Lapack distribution that you're using.
Thanks,
Jeremy
On 12 Oct 2018, at 01:05, Amitvikram Dutta <amitvdutta23@gmail.com> wrote:
Hi all,
I keep having the same problem while trying to install nektar++ with regards to the Lapack libraries.
When I try to use the system Lapack installation I get the following message
*/scinet/bgq/Libraries/lapack/lib/liblapack.so: undefined reference to `_xlfEndIO@XLF_1.0'*
while when I try to install using the ThirdParty Lapack supplied with the nektar++ source directory I get the following error
*../../library/LibUtilities/libLibUtilities.so.4.4.1: undefined reference to `dtpmv_'*
I have a feeling these errors have been encountered by the community at large before. Could someone point out where I'm going wrong?
Sincerely, --
*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
-- Chris Cantwell Imperial College London South Kensington Campus London SW7 2AZ Email: c.cantwell@imperial.ac.uk www.imperial.ac.uk/people/c.cantwell
--
*Amitvikram Dutta*
Graduate Research Assistant
Fluid Mechanics Research Lab
Multi-Physics Interaction Lab
University of Waterloo
--
*Amitvikram Dutta* Graduate Research Assistant Fluid Mechanics Research Lab Multi-Physics Interaction Lab University of Waterloo