Install Applications and Libraries in the Home Directory¶
Typically, a user has the permissions to compile and "install" their own libraries and applications. Obviously, a non-root user cannot write to the protected systems library directories, but there is enough space in their home directory, work or project directory to store such tools and libraries.
Introduction¶
Typically, a user has the permission to compile and install extra libraries and applications in his/her home, work or project directory, where there is enough space to store such tools and libraries. However, at first please check our list. If a library or an application on the block list was installed without permission, it may be harmful to the HPC environment and the user will be warned or even have his/her account disabled.
Please contact us if you are unsure about whether an installation is appropriate or need help for the installation.
Blocklist¶
glibc¶
We do not allow users to install any version of glibc in their own directory on our HPC supercomputer clusters, because glibc is integrated into the operating system and the installation will cause security issues. Therefore, we do not support using a self-installed version of glibc. If you need to link your package to glibc, please link it to the default system-wide installation of glibc; if you have source code, please recompile it using the system-wide installation of glibc; if only a binary is available, please provide us what the code is, where it comes from and if it is licensed for the trouble-shooting, or ask the developer to compile the code with the same glibc version as our system-wide installation of glibc.
Applications¶
FFTW¶
The latest official version of FFTW can be obtained at www.fftw.org. If you are still considering to use FFTW 2.x, please note that FFTW 2.x was last updated in 1999 and it is obsolete. So please install FFTW 3.x.
To install FFTW3, copy the FFTW3 tarball to the home directory and unpack it. Then rename the new directory to /tmp and change to it.
tar -xvzf fftw-3.3.4.tar.gz
mv fftw-3.3.4 tmp
cd tmp
Next, in the configure step, specify the install destination with the --prefix option. Meanwhile, the customization of FFTW should be well checked during the configuration step (e.g. whether a serial or parallel version should be installed). For the full description of the FFTW, please carefully read the introduction at www.fftw.org/fftw2_doc/fftw.html. For example, the following configure program will install a parallel single-precision version of FFTW with shared libraries:
./configure --prefix=$HOME/fftw-3.3.4 --enable-float --enable-shared --enable-mpi -mpicc --enable-sse2
Here the --enable-float flag produces a single-precision version of FFTW; --enable-shared creates shared libraries; --enable-mpi flag enables compilation and installation of FFTW MPI library with a specified compiler.The version of MPI compiler can be obtained with which command which mpicc. The last --enable-sse2 flag is to compile FFTW to support SIMD (single instruction multiple data) instructions. This is asked by some self-installed software such as Gromacs for better performance when linking your self-installed FFTW.
After the configuration, use GNU make and make install to finish the installation.
make
make install
To test FFTW for correctness, make check can be used to put the FFTW test programs through their paces. For instance, the following command line combines the error message (if any) with standard output, and then dumps the output to a log file named check.log. Failures are not necessarily problems as they might be caused by missing functionality, but a careful look at any reported discrepancies is required.
make check 2>&1 | tee check.log
Alternatively, examine the binaries in the fftw-3.3.4/bin with ldd command, as well as check if the library files in the fftw-3.3.4/lib has suitable extensions (.so for shared library; .a for static library).
If problems occurred during configuration or compilation, use make distclean before trying again; this ensures that you don't have any stale files left over from previous compilation attempts.
Finally, if the installation looks good, add relative paths to the shell initialization script under home directory. For a bash shell, after opening the .bash_profile , type:
#added path to fftw
export PATH=$HOME/fftw-3.3.4/bin:$PATH
export LD_LIBRARY_PATH=$HOME/fftw-3.3.4/lib:$LD_LIBRARY_PATH
export LIBRARY_PATH=$HOME/fftw-3.3.4/lib:$LIBRARY_PATH
export PKG_CONFIG_PATH=$HOME/fftw-3.3.4/lib/pkgconfig:$PKG_CONFIG_PATH
#end
Once finished, remember source this file or relogin to the cluster to take effect the change. The tmp directory may be deleted.
R¶
Introduction
The 2016 or later version of R has removed the versions of several compression libraries required by the installation that used to be included, such as zlib, bzip2xz, curl and pcre. The R package assumes those libraries are all up-to-date in the operating system.
A R package released in 2016 or later can give an error message like this:
checking if zlib version >= 1.2.5... no
checking whether zlib support suffices... configure: error: zlib library and headers are required
From the HPC administrator's point of view, we are unwilling to update the support libraries system-widely very often, because the defects (bugs) of the new libraries may be harmful to other existing software.
But it is possible for the user to compile and install all support libraries (zlib, bzip2xz etc.) in the home directory without system-wide intervention. To do so, please refer to an article written by Prof. Johnson at here.
Installation
If Intel compiler is used, please note if the default compiler on the cluster is Intel 14, it does not support _Alignof in C11, which will fatally terminate the make process. Therefore, a newer version of Intel compiler is required. Intel 15.0.0 and Intel 16.0.3 have been used to compile R respectively, and the tests of installation were successful. Before the installation of R, unload the default Intel compiler and load the newer one with module:
module unload intel/14.0.2
module load intel/16.0.3
Note: Any values in the environment variable R_LIBS_USER should be removed by the command unset R_LIBS_USER before installing R.
According to an article at R-bloggers and other online resources, it is recommended to use Math Kernel Library (MKL) optimized for Intel processors, with performance far superior to traditional libraries, as well as to have the capabilities of multi-threading.
To install R, copy the R tarball to the home directory and unpack it. Then rename the new directory to tmp and change to it.
tar -xvzf R-3.5.1.tar.gz
mv R-3.5.1 tmp
cd tmp
Specify the install destination (the home directory), the use of Intel compiler and MKL in the configuration:
fast="-ip -O3 -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise"
./configure --prefix="$HOME/r-3.5.1" CC=icc CFLAGS="$fast -wd188" CXX=icpc \ CXXFLAGS="$fast" FC=ifort FCFLAGS="$fast" F77=ifort FFLAGS="$fast" \
--with-blas='-mkl=parallel' --with-lapack
If using Intel 18 compiler or later, replace -opt-mem-layout-trans=3 with -qopt-mem-layout-trans=3
The last two options is for MKL support. The --with-blas option compiles a special version of BLAS library supported by MKL. If more precise control than -mkl=parallel is desired, please read the MKL User's Guide or see the website of the Intel MKL Link Line Advisor. Some good examples of detailed --with-blas flag options can be found here, here, here and here. The --with-lapack option compiles a special version of LAPACK library supported by MKL.
Note: --enable-R-shlib is necessary to create libR.so, which is required for building RStudio and several other R packages such as svcm.
Check if R_LIBS_USER is used, it should be unset before the installation.
Then use GNU make and make install to finish the installation.
# compiling in parallel. Where -j is the # of cores on the node.
make -j 20
make install
After make install, to check if MKL library was dynamically linked in the R, you may use ldd command to verify:
$ ldd $HOME/r-3.5.1/lib64/R/bin/exec/R
linux-vdso.so.1 => (0x00007fffd87ff000)
libmkl_intel_lp64.so => /usr/local/compilers/Intel/cluster_studio_xe_2013.1.046/composer_xe_2013_sp1.2.144/mkl/lib/intel64/libmkl_intel_lp64.so (0x00002ba734fe5000)
......
In the R test, make check can be used to put the R test programs through their paces. Please note since R-3.6.0, R adds a new test package called "exSexpr" that requires LaTex. Since LaTex is not available on our clusters, the test will give an error related to latex creating the PDF package manuals, making the whole test fail. So if needed, make check may be replaced by make test-Examples, which runs all the examples from the help files (*.Rd) of all core packages(base, ctest, ..., ts).
make check
# for R-3.6.0 or later:
cd tests
make test-Examples
Finally, if the installation looks good, add relative paths to the shell initialization script under home directory. For a bash shell, after opening the .bash_profile , type:
Once finished, remember source this file or re-login to the cluster to take effect the change. The /tmp directory may be deleted once the installation has done.
GCC¶
The GNU Compiler Collection (GCC), likely best known by its gcc C compiler, is already installed on all of our supercomputer clusters. The detail of system-wide installed gcc can be found here.
If you need your own GCC, since you don't have root privilege, you need to install it from the source code rather than yum install. So first of all, please download the source code. Simply google "gcc source download", and download the tarball (e.g. gcc-5.5.0.tar.gz) from the mirror website. Copy the gcc-5.5.0.tar.gz tarball to the home or project directory and unpack it. Then rename the new directory to tmp and change to it.
tar -xvzf gcc-5.5.0.tar.gz
mv gcc-5.5.0.tar.gz tmp
cd tmp
Next, run the gcc./contrib/download_prerequisites script in the GCC source directory. That will download the support libraries and create symlinks, causing them to be built automatically as part of the GCC build process.
./contrib/download_prerequisites
The GCC developers highly recommend that GCC should be built into a separate directory from the sources which does not reside within the source tree. A major benefit of running srcdir/configure from outside the source directory (instead of running ./configure) is that the source directory will not be modified in any way, so if your build fails or you want to re-configure and build again, you simply delete everything in the build directory and start again. Therefore, before the configuration, exit the source directory first, make a build directory "gcc-5.5.0" and then change to it.
cd ..
mkdir gcc-5.5.0
cd gcc-5.5.0
Next, in the configure step, specify the install destination with the --prefix option and other flags
$PWD/../tmp/configure --prefix=$HOME/gcc-5.5.0 --enable-languages=c,c++,fortran,go CC=gcc \ CXX=g++ --disable-multilib
Here --enable-languages specifies that only a particular subset of compilers and their runtime libraries should be built. If you do not pass this flag, or specify the option default, then the default languages available in the gcc sub-tree will be configured. CC=gcc and CXX=g++ ask using system-widely installed GCC compiler to compile the gcc-5.5.0 source code. In this example, gcc 4.9 is used. --disable-multilib is applied because a 64-bit-only GCC compiler will be built. If this flag was not specified, A error message "configure: error: I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib." will appear. And --enable-multilib is not a good choice. Build will fail with "fatal error: gnu/stubs-32.h: No such file or directory", because our system does not have 32-bit development libraries (libc and headers), and we do not allow any users to install their version of glibc in their own directory on any HPC clusters.
After the configuration, use make and make install to finish the installation. The make command could take several hours.
make
make install
To test GCC for correctness, the following command line gives you both version and programs invoked by the newly installed compiler.
$ ./bin/gcc -v
Using built-in specs.
COLLECT_GCC=./bin/gcc
COLLECT_LTO_WRAPPER=/worka/project/ychen64/gcc-5.5.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /project/ychen64/gcc-5.5.0/../tmp/configure --prefix=/project/ychen64/gcc-5.5.0 --enable-languages=c,c++,fortran,go CC=gcc CXX=g++ --disable-multilib
Thread model: posix
gcc version 5.5.0 (GCC)
Also, you may create a Hello World to see if it links and compiles properly. Create a file named test.c with the following in it:
Then compile test.c and run it.
./bin/gcc test.c -o test
./test
Finally, if the installation looks good, add relative paths to the shell initialization script under home directory. For a bash shell, after opening the .bash_profile, type:
# added path to gcc
export PATH=~/gcc-5.5.0/bin:$PATH
export LD_LIBRARY_PATH=~/gcc-5.5.0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=~/gcc-5.5.0/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=~/gcc-5.5.0/lib/gcc/x86_64-unknown-linux-gnu/5.5.0:$LD_LIBRARY_PATH
export LIBRARY_PATH=~/gcc-5.5.0/lib:$LIBRARY_PATH
export LIBRARY_PATH=~/gcc-5.5.0/lib64:$LIBRARY_PATH
export MANPATH=~/gcc-5.5.0/share/man:$MANPATH
Once finished, remember source this file or re-login to the cluster to take effect the change. The tmp directory may be deleted.
Python¶
If a specific version of Python is needed for building other software (e.g. qiime2) or a specific python module in the Conda Virtual Environment, we recommend Miniconda, which is a mini version of Anaconda that includes only conda and its dependencies. It does not require administrator permissions to install.
The latest Miniconda can be downloaded as Miniconda2 or Miniconda3. Miniconda2 is Python 2 based and Miniconda3 is Python 3 based. Note that the choice of which Miniconda is installed only affects the root environment. Regardless of which version of Miniconda you install, you can still install both Python 2.x and Python 3.x environments. The other difference is that the Python 3 version of Miniconda will default to Python 3 when creating new environments and building packages. So for instance, the behavior of
conda create -n myenv python
will be to install Python 2.7 with the Python 2 Miniconda and to install Python 3.6 with the Python 3 Miniconda. You can override the default by explicitly setting python=2 or python=3 in the conda create command when creating the Conda Virtual Environment. It also determines the default value of CONDA_PY when using conda build.
First, choose one of the following commands to download the installer script:
wget https://repo.continuum.io/miniconda/Miniconda2-latest-Linux-x86_64.sh
wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh
Next, load system-widely installed Python 3.5 or Python 3.6 to install Miniconda. Python 2 on the cluster doesn't have some required packages for building Miniconda, so only Python 3 can work. For example:
module load python/3.6.4-anaconda
Unset environmental variables PYTHONPATH and PYTHONUSERBASE before the Miniconda installation:
unset PYTHONPATH
unset PYTHONUSERBASE
Install Miniconda2 is straightforward:
bash Miniconda2-latest-Linux-x86_64.sh
or for Miniconda3
bash Miniconda3-latest-Linux-x86_64.sh
Use conda list command to verify Miniconda has been installed successfully. If see ImportError: No module named site, type unset PYTHONHOME will fix the issue. Once the Miniconda has been installed, the system-wide installed Python 3 doesn't have to, or shouldn't be loaded anymore.
If you already have a Miniconda or Anaconda installed, and you want to upgrade it, you should not use the installer script once more. Instead, just use conda update. For instance:
conda update conda
Libraries¶
R¶
Installation¶
If a system-wide installed R is used, the default R library path is /home/packages/r/3.x.x/INTEL-14.0.2/lib64/R/library, which is not writable if a user do not have root privilege. To install a R package, the environment variable R_LIBS_USER needs to be pointed to a desired location in your own directory. For example, when using bash shell you would issue a command similar to the following:
export R_LIBS_USER=$HOME/packages/R/libraries
The above command line can be added to the default shell initialization environment by pasting the line to the script such as .bash_profile under your home directory. If the R is installed in your home directory, the above step is unnecessary but can be considered if you wish to have two directories for the default and new libraries respectively.
Type R to enter the console, then run R commands there.
R
_(introduction section)_
...
To see libraries that R currently searching, use:
.libPaths ()
Use install.packages("(package name)") function (double quotation is mandatory) to install package. For example, to install the package glmnet:
install.packages ("glmnet",repos="http://cran.r-project.org")
Then select a CRAN mirror (e.g. 144 USA (TX)) to install the package glmnet.
Load, update and remove packages¶
When in the R console, the library() function checks all of the previously installed packages. the library()function can also be used to load a specified installed package:
library ("glmnet")
Packages can be updated, as well as removed in the R session:
update.packages ("glmnet")
remove.packages ("glmnet")
Python¶
Installation¶
Python modules can be treated as libraries. Each module comes with reusable codes. On our supercomputer clusters several well-known Python modules such as NumPy have been installed system-widely (globally). However, if you prefer to use modules that haven't been installed, or wish to use a certain version of the module rather than the system-wide version on the cluster, you may find the default Python module path is not writable for module installation as you do not have root privilege.
Therefore, you may consider to install your desired Python modules in your home directory, and the module installation can be done using a Python module called pip. Note the module pip is not provided by the default Python (2.6) on some of our clusters, so a newer version of Python (check our current versions and availability) has to be loaded by softenv or module to use pip. After loading Python, make sure pip is available by some commands such as which pip or pip --version.
Once pip is available, it is important to know the directory saving your local-installed modules. The default location is explained in the Python documentation for the site.USER_SITE and site.USER_BASE variables. The default value of the former is ~/.local/lib/pythonX.Y/site-packages which can be modified by the PYTHONPATH environment variable; while the default value of latter is ~/.local variable which can be modified by the PYTHONUSERBASE environment variable.
Therefore, by updating PYTHONPATH and PYTHONUSERBASE at the same time, you may specify your desired install location in your home directory. For example, if using Python 2.7, to specify a module install location ~/packages/python, following command (when using bash) should be used:
export PYTHONPATH=$HOME/packages/python/lib/python2.7/site-packages:$PYTHONPATH
export PYTHONUSERBASE=$HOME/packages/python
The above command lines should be added to the default shell initialization environment by pasting the line to the script such as .bash_profile under your home directory. Even you choose to use the default ~/.local/lib/pythonX.Y/site-packages, you should add export PYTHONPATH=$HOME/.local/lib/python2.7/site-packages:$PYTHONPATH to your default shell initialization environment (.bash_profile). This is because when the location of globally installed modules is also in the PYTHONPATH, sometimes it has precedence over the local path. If that is the case, Python will load the globally installed modules instead of your local modules. In other words, even you have already installed your desired module locally, Python will choose to load the globally installed module, which is the one you don't like, over the local one if you did not add the export PYTHONPATH=$HOME/.local/lib/python2.7/site-packages:$PYTHONPATH to your .bash_profile. Thus, please be careful and make sure the PYTHONPATH contains your local module installation path and it is before the system-wide path.
Once the pip is setup, the newest version of pip should be installed:
pip install --user --upgrade pip
The --user option can turn on the site.USER_SITE variable and ask pip to install any new modules (including itself here) into your home directory.
The following command will give you the exact version and location of the installation of pip that your Python is seeing:
python -m pip --version
The following command will give you the location of pip in PATH
which pip
If the PATH only has system-wide installed pip, while Python is seeing a different pip in your home directory, an error message will occur when trying to launch pip:
pip list
Traceback (most recent call last):
File ".../pip", line 7, in
from pip._internal import main
ImportError: No module named _internal
The solution is adding the pip bin(e.g. $HOME/packages/python/bin) to the PATH .
Once pip is available, to list all of the current installed modules, or just list one or several modules. Use the following commands respectively:
pip list # list all moudles available
pip show module_name # list a module called "module_name"
Now you may have a clear view of the modules currently installed. If you cannot find the module you need, or you wish to use a different version, you may use one of the following methods, and remember to include the --user option:
pip install --user module_name # latest version
pip install --user module_name==x.y.z # specific version x.y.z
pip install --user 'module_name>=x.y.z' # minimum version
Sometimes after typing pip install module_name, you will get the following message:
pip install --user module_name
Requirement already satisfied: module_name in ./.local/lib/python2.7/site-packages
Requirement already satisfied: python-dateutil in ./.local/lib/python2.7/site-packages
...
And the installation will be terminated. This is because Python and pip apply a mechanism to manage the modules install. With the mechanism, pip sometimes will consider the globally installed modules already satisfy the installation requirements and does nothing, and reports that "requirement is satisfied". If you need more precise control, you may take a look a the pip user guide about the requirement files. If not, just use the second method pip install module_name==x.y.z to specify the module version. If still got this issue, consider to add --upgrade option.
Listing modules¶
pip list and pip show module_name can be used to list all of the current installed modules and list one or several modules, respectively. For more information, please see pip list and pip show reference pages.
Upgrade/downgrade modules¶
Add --upgrade option to upgrade module. The module may be downgraded with the same option. In the following the second method is preferred as it is more precise and can be used to downgrade modules:
pip install --upgrade --user module_name # latest version
pip install --upgrade --user module_name==x.y.z # specific version x.y.z
Uninstallation¶
Simply use:
pip uninstall module_name
Conda (TensorFlow)¶
Conda¶
Conda is an open source package management system and environment management system. Besides TensorFlow, Conda can install many other pre-built, reviewed and maintained Python packages.
Prerequisites¶
Alternatively, a Python version installed in user's directory (/home or /work) can be used to install use's own version of TensorFlow. This can avoid some known issues from system-wide installed Python which is not updated frequently and provide newer features and more up-to-date Python libraries than the system-wide installed version. However, users should be aware that the self-installed newer TensorFlow versions might also have unpredictable problems.
If a specific version of Python is needed, Miniconda is recommended.
Python in conda virtual environment
A Conda virtual environment is an isolated working copy of Python which enables multiple side-by-side different installations of Python environments without affecting each other. Therefore it is recommended in situation when a specific python library such as TensorFlow needs to be installed/upgraded. conda can create virtual environment for both Python library dependencies and non-Python library dependencies, the latter do not have a setup.py in their source code and also do not install files into Python's site-packages directory.
The conda virtual environment can be either Python 2 based or Python 3 based and you can create either Python 2.x or Python 3.x conda virtual environment regardless of the current Python module version you are using, that is to say, you can use a current Python 2.x version to create a Python 3.x virtual environment and vice versa.
Some combinations of system-wide installed Python and Python in conda virtual environment are not working well. When using Python 2.7 (python/2.7.13-anaconda-tensorflow), PYTHONPATH need to be unset before loading TensorFlow. Also, avoid TensorFlow loading with Python 2.x in conda virtual environment as it will fail with an issue that cannot be easily fixed.
Disk space used by virtual environment¶
When creating an environment, conda will download large amount of installation tarballs to the package cache directory. The default is ~/.conda/pkgs in /home directory, however on all HPC clusters, user's /home directory has a quota. Therefore, instead of using this default setting, the downloaded package cache directories needs to be redirected to a different location, which can be specified in the .condarc file. Below steps listed steps for redirecting the package cache location:
Edit conda user config file: ~/.condarc to redirect the cache directories. For example, after opening ~/.condarc, add following lines to change the cache directories to /work:
envs_dirs:
- /work/your_username/test-env/envs
pkgs_dirs:
- /work/your_username/test-env/pkgs
Installation¶
The TensorFlow installation process can be computational intensive so make sure you do this on a compute node through interactive job.
Due to possible package conflicts that might cause various issues during the installation and runtime of TensorFlow. Before trying to install tensorflow through conda environment, do a module purge to cleanup the current environment:
module purge
Then load a Python module.
module load python/3.6.2-anaconda-tensorflow
Check conda information. If conda is available, you will see:
conda info
Current conda install:
platform : linux-64
conda version : 4.3.27
...
...
envs directories : /work/your_username/test-env/envs
/home/your_username/.conda/envs
/usr/local/packages/python/3.6.2-anaconda/envs
package cache : /work/your_username/test-env/pkgs
...
Also make sure the cache directories (envs directories & package cache in the conda info result) have been redirected to another directory. (/work/your_username/test-env/pkgs in the example above) If not, refer to the method mentioned in the above Disk space used by virtual environment section.
Next is to create conda virtual environment. Now create a conda environment called "tf" by:
conda create -n tf python=3.6
unset PYTHONPATH
unset PYTHONHOME
The conda environment name is arbitrary, it can be named as "tf-1.8.0", "tensorflow-1.8.0" etc. The command above creates a Python 3.6 conda environment tf. If Python 2.7 conda environment is preferred, change the argument python=3.6 to python=2.7 in the command line. Note files in the work directory are subject to be purged after 60-90 days. If /project is available to the user, the conda virtual environment should be created in /project .
The the conda environment should then be activated before installing TensorFlow (note in some new version of conda, the command is conda activate tf):
source activate tf
Finally TensorFlow can be installed from the anaconda channel:
conda install -c anaconda tensorflow
If a specific version of TensorFlow is needed, add the version after the tensorflow keyword above. For example, to install TensorFlow 1.8:
conda install -c anaconda tensorflow=1.8
If gpu is needed to run TensorFlow, change the argument tensorflow to tensorflow-gpu in the command line:
conda install -c anaconda tensorflow-gpu
Only compute nodes with GPU installed can be used for tensorflow-gpu. The nvidia-smi command can be used to monitor the GPU devices.
Please remember never run TensorFlow on the headnode!
Test if you can load TensorFlow:
$ python
Python 3.6.2 |Continuum Analytics, Inc.| (default, Jul 20 2017, 13:51:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow
>>> tensorflow.VERSION
'1.12.0'
Pay attention to the TensorFlow version you got. If you found a much lower version than you expected, then the system-widely installed TensorFlow is loaded by mistake. Unset the value of PYTHONPATH can fix this issue.
Known issues¶
conda environment missing from list
The description of the issue in detail can be found here. This issue was resolved in conda 4.4. In the past, the system-wide installed Python was conda 4.3, so after typing conda env list the conda environment will not be listed. The conda environment, however can always be found in the file ~/.conda/environments.txt.
cd ~/.conda
cat environments.txt
"AttributeError: module 'enum' has no attribute 'IntFlag'"
Using system-wide installed python/2.7.13-anaconda-tensorflow, no matter which version of Python in conda virtual environment is created, will give "AttributeError: module 'enum' has no attribute 'IntFlag'" when loading TensorFlow. Unset the value of PYTHONPATH can fix this issue.
Failure of CUDA session creation
When TensorFlow-gpu is installed, there is recent upgrade of tensorflow version in the conda anaconda channel to cudatoolkit version 9. when default command was used to install TensorFlow, the conda virtual environment will use the default condatoolkit version 9 which also requires higher version of Nvidia driver which will cause failure of CUDA session creation. This kind of issue will appear in the future versions of TensorFlow's installation as long as there is mismatch between cudatoolkit and the nvidia driver.
Solution is to specify the cudatoolkit version during installation, below is an example (also you can try different version combinations, some combinations might fail).
conda install -c anaconda cudatoolkit=8 tensorflow-gpu=1.7 tensorflow-gpu-base=1.7
"libstdc++.so.6: version `GLIBCXX_3.4.22' not found"
If gcc 4.9 as loaded during the TensorFlow installation, when loading TensorFlow, it will give "libstdc++.so.6: version `GLIBCXX_3.4.22' not found". Need unload gcc 4.9 in Module when using TensorFlow.
"libtensorflow_framework.so: symbol GOMP_parallel, version VERSION not defined in file libiomp5.so with link time reference"
Using system-wide installed Python 2.7 along with Python 2.7 in conda virtual environment for installing TensorFlow 1.12 will give the error above. It is not fixable at this time.
"TypeError: new() got an unexpected keyword argument 'file'" (TensorFlow 1.8) "TypeError: new() got an unexpected keyword argument 'serialized_options'" (TensorFlow 1.12)
Using system-wide installed Python 2.7 or Python 3.6 along with Python 2.7 in conda virtual environment for installing TensorFlow 1.8 will give the error above. Python 3.6 along with Python 2.7 in conda virtual environment for installing TensorFlow 1.12 will also give the similar error.
There are suggestions online to upgrade/downgrade protobuf that we were not able to replicate successfully.
This issue is not fixable at this time.
Tutorial and test code¶
Tutorial and test code are available on our website. Check out our latest training sessions about TensorFlow and other deep learning tools.