tensorflow: Open-source software library for machine intelligence

Overview of package
1. General usage
Availability of package by cluster
Using Singularity based tensorflow installations

Overview of package

General information about package
Package:	tensorflow
Description:	Open-source software library for machine intelligence
For more information:	https://tensorflow.org/
Categories:	ComputerVision MachineLearning NumericalMethods PythonModule
License:	OpenSource (Apache License 2.0)

General usage information

Tensorflow is an open-source software library for machine intelligence. It has a comprehensive, flexible ecosystem of tools, libraries and community resources that lets developers easily build and deploy machine-learning powered applications.

This module will add the tensorflow and tensorboard modules to your PYTHONPATH

Available versions of the package tensorflow, by cluster

This section lists the available versions of the package tensorflowon the different clusters.

Available versions of tensorflow on the Zaratab cluster

Available versions of tensorflow on the Zaratab cluster
Version	Module tags	CPU(s) optimized for	GPU ready?
2.8.1	tensorflow/2.8.1	zen2	Y
2.2.0	tensorflow/2.2.0	zen	Y
2.14.0	tensorflow/2.14.0	icelake, zen2	Y
2.7.1	tensorflow/2.7.1	zen2	Y

NOTE: The installations on Deepthought2 RHEL6 nodes are all Singularity based installations. For more information, please see the section Using Singularitiy based tensorflow installations.

Using Singularity based tensorflow installations

The keras, tensorflow, and theano packages are not natively installed on the Deepthought2 RHEL6 nodes for various technical reasons. What is provided instead are Singularity containers which have versions of both python2 and python3 installed with these packages.

To use these python packages, you must load the appropriate environmental module (e.g. module load tensorflow) and then launch the python interpretter inside the Singularity container. To help with this, the following helper/wrapper scripts have been provided: >tensorflow or tensorflow-python2 will invoke a Tensorflow-enabled python2 interpretter within the container. Any arguments given will be passed to the python command, so you can do something like tensorflow myscript.pl

tensorflow-python3 will behave as above, but invoke a Tensorflow-enabled python3 interpretter within the container.

tensorboard, tensorboard-python2 will run the tensorboard command (using python2) inside the container. Any arguments provided will be passed to the tensorboard command.

saved_model_cli, saved_model_cli-python2 will run the saved_model_cli command (using python2) inside the container. Any arguments provided will be passed to the saved_model_cli command.

tensorboard-python3, saved_model_cli-python3 will behave similarly to the tensorboard and saved_model_cli commands above, but will use python3 variants of the scripts.

In all cases, any arguments given to the wrapper scripts are passed directly to the python interpretter running within the container. E.g., you can provide the name of a python script, and that script will run in the python interpretter running inside your container. Your home and lustre directories are accessible from within the container, so you can read and write to files in those directories as usual.

Note that if you load the keras environmental module and then issue the python command, you will start up a natively installed python interpretter which does NOT have the tensorflw, etc. python modules installed. You need to start one of the python interpretters inside the container to get these modules --- you can either do that using the correct singularity command, or use the friendlier wrapper scripts described above.

It is hoped that for most users, the "containerization" of these packages should not cause any real issues, and hopefully not even really be noticed. However, there are some limitations to the use of containers:

In general, you will not have access to natively installed software, just the software included in the container. So even if some package foo is installed natively on Deepthought2, it is likely not accessible from within the container (unless it was also installed inside that container).
You will not likely be able to use python virtualenv scripts to install new python modules for use within the container, as that will be installing packages natively, which would not then be available inside the container.