Introduction

Nektar++ uses a CMake-based build system. The build system has developed extensively over the past few years and now handles building many third-party dependencies automatically as part of the process of building Nektar++ from source code.

However, high-performance computing infrastructure such as large-scale clusters and other specialist platforms are sometimes configured to prevent their users from making outgoing network connections, such as HTTP/HTTPS connections, to the public Internet.

This causes problems for building Nektar++ on such platforms when third party dependencies must be downloaded from the Internet by the build system as part of the configuration/build process.

This blog post explains how to manually work around this issue by placing the correct third party dependencies in the correct location on the target system such that Nektar++ is able to discover and use them during the build process without needing to attempt to download the files.

Note that this post focuses on Unix-based systems only.

Prerequisites

The details in this post assume the following:

• You have some form of terminal-based remote network access to your target platform (e.g. SSH (Secure Shell))
• Your target platform provides a means to securely upload files to it – we assume the use of SCP (Secure Copy).

Dependencies

Nektar++ has some required dependencies as well as some optional dependencies that are needed when specific features are enabled.

The core third party dependencies are:

• TinyXML – A lightweight C++ XML parser
• BLAS/LAPACK – Libraries providing core linear algebra operations (different libraries may be used but we focus on the Netlib BLAS/LAPACK implementations here)
• Boost – A set of widely-used, portable C++ libraries
• Loki – Design patterns (Nektar++ versions before 4.5.0/master)
• zlib – Compression library

As part of the CMake configuration process, the Nektar++ build system will attempt to find dependencies on the local system. Where these dependencies cannot be found, the build system will set itself up to build the dependencies automatically. If you use the CMake curses-based user interface, ccmake, you can see after configuring which third party dependencies will be built by looking at the THIRDPARTY_BUILD_* options to see which of these options are set to ON.

Additional dependencies that can be built as part of the Nektar++ build and are required for optional features:

• Scotch – Sparse matrix block ordering; graph, mesh and hypergraph partitioning
• gsmpi – supporting routines for MPI
• METIS – Graph partitioning library – required when NEKTAR_USE_METIS is enabled
• HDF5 – Support for the HDF5 file format. Required when NEKTAR_USE_HDF5 is enabled
• FFTW – FFT support that can be used by some of the functions within Nektar++. Required when the NEKTAR_USE_FFTW option is enabled
• ARPACK – Eigenvalue support library required when the NEKTAR_USE_ARPACK library option is enabled.
• CWIPI – Coupling library – required when the NEKTAR_USE_CWIPI option is enabled
• Open CASCADE Community Edition – Library used in mesh generation when the NEKTAR_USE_MESHGEN option is enabled
• Tetgen – Tetrahedral mesh generation – required when the NEKTAR_USE_MESHGEN option is enabled
• PETSc – Library providing efficient, scalable PDE solving – required when the NEKTAR_USE_PETSC option is enabled
• VTK – visualisation toolkit – required for building of some pre/post-processing tools.modules – required when the NEKTAR_USE_VTK option is enabled

You can find further details of the prerequisites for building Nektar++ in the user manual: http://doc.nektar.info/userguide/latest/user-guidese3.html#x7-60001.3

Preparing your build

Since you’re building on a platform that doesn’t have external Internet access, you’ll need to clone the Nektar++ git repository or download a tarball of the source code for your required release version on a separate system and move the source code to the build environment. If you clone the git repository, you’re recommended to bundle the source code into a tar.gz or similar archive file to make it easier to copy the files to the build platform. As an example, you might do something like the following to prepare a Nektar++ 4.4.1 build:

git clone https://gitlab.nektar.info/nektar/nektar.git
cd nektar; git checkout v4.4.1; cd ..
tar zcvf nektar-4.4.1-src.tar.gz nektar
scp nektar-4.4.1-src.tar.gz <my-cluster-username@my-cluster.hostname>:/home/<my-cluster-username>

In addition to the Nektar++ source, you’ll need to obtain the third party dependency tarballs. Most of these can be obtained via http://www.nektar.info/thirdparty. There is one exception – the Lapack software must be obtained directly from netlib.org – for example, version 3.7.0 of BLAS/LAPACK can be accessed at http://www.netlib.org/lapack/lapack-3.7.0.tgz.

Again, you’ll need to download the required files on a separate system and copy them to the target build platform. If you’re downloading the files via a terminal, you can use a tool such as wget to do this.

NOTE: One of the key things you need to ensure is that you have the correct versions of the dependencies for the version of Nektar++ that you’re building. For now, these versions are detailed at the end of this blog post, however, going forward, we intend to provide functionality that will enable you to obtain a list of the required dependencies/versions from the build system.

We’ll refer to the top-level Nektar++ source directory – the directory that you obtain when extracting a tarball from the website or cloning from GitLab – as ${NEKTAR_SRC}. You should create the directory ${NEKTAR_SRC}/ThirdParty and place all of the required third party dependency tarballs into this directory.

In the case of two of the tarballs – loki and lapack, these must be extracted in the ${NEKTAR_SRC}/ThirdParty directory before you attempt to configure and build Nektar++.

NOTE: You only need to include the tarballs for the dependencies that are not already available on your target platform.

Once all of the tarballs are in place in the ${NEKTAR_SRC}/ThirdParty directory, you can proceed to build from source in the same way as described in the Nektar++ build documentation.

BLAS/LAPACK Third Party Build

One thing to note if you require CMake to build BLAS/LAPACK as part of the Nektar++ build is that both the THIRDPARTY_BUILD_BLAS_LAPACK and NEKTAR_USE_SYSTEM_BLAS_LAPACK options must be set to ON in order for this to work correctly. If THIRDPARTY_BUILD_BLAS_LAPACK=ON but NEKTAR_USE_SYSTEM_BLAS_LAPACK=OFF, you will see linking errors relating to BLAS/LAPACK symbols when the Nektar++ libraries are linked.

You should therefore ensure you have the following configuration when building third party BLAS/LAPACK:

THIRDPARTY_BUILD_BLAS_LAPACK=ON
NEKTAR_USE_SYSTEM_BLAS_LAPACK=ON

Third-party Dependency Overview

We now provide an overview of the third-party dependencies, their associated parameters and versions/links for the current release at the time of writing (4.4.1) and the current git master (pre-4.5.0):