Editing CommunityData:Hyak software installation

From CommunityData
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 18: Line 18:
=== Python Packages ===
=== Python Packages ===


Our setup on Mox provides the Anaconda python distribution.  
DO NOT TRUST THIS SECTION. Intel python appears to have some issues.  


Using an anaconda python distribution has important implications for how you install packages. While in normal python, you would install python packages using `pip`, when you use an anaconda distribution you should use <code>conda</code> to install packages. Conda also has some fancy features like virtual environments for using different versions of python or different versions of packages in different projects. The problem with using conda is that it does not include all the packages you might want to use. If you want to install a python package that is missing from conda, you can use pip. ''Importantly, you should prefer to install software using conda over pip.''
The recommended python to use on hyak is the intel-python. This is a customized anaconda distribution with a magical optimization of python that really increases the performance of numpy.  


Details on both are here:
Using an anaconda python distribution has important implications for how you install packages. While in normal python, you would install python packages using `pip`, when you use an anaconda distribution you should use `conda` to install packages. Conda also has some fancy features like virtual environments for using different versions of python or different versions of packages in different projects. The problem with using conda is that it does not include all the packages you might want to use. If you want to install a python package that is missing from conda, you can use pip.


* [https://conda.io/docs/ Conda Documentation]
Importantly, when using intel-python, you should prefer to install software using conda over pip.  
* [https://pip.pypa.io/en/stable/ Pip Documentation]


It's often a good idea to create new environments for installing software you will use in each project. This way you can use the latest and greatest versions of packages, but you'll still be able to run code in your old projects. To create a new conda environment:
[https://conda.io/docs/ Conda Documentation]
[https://pip.pypa.io/en/stable/ Pip Documentation]


<syntaxhighlight lang='bash'>
The first time you use intel-python you need to create a custom environment for installing software:  
$ conda create -n my_root
</syntaxhighlight>
Then add the following to your .bashrc to use this environment automatically by default:


<syntaxhighlight lang='bash'>
    conda create -n my_root
if [ -z $(conda info --env | grep my_root | grep \*) ]; then
 
    source activate my_root
Then add the following to your .bashrc to use this environment.
fi
    if [ -z $(conda info --env | grep my_root | grep \*) ]; then
</syntaxhighlight>
        source activate my_root
Conda doesn't like it when you try to activate an environment that is already active.  
    fi
 
Conda doesn't like it when you try to activate an environment that is already active. T


Conda modifies your prompt in a possibly annoying way. To disable this behavior run the command:  
Conda modifies your prompt in a possibly annoying way. To disable this behavior run the command:  
    $ conda config --set changeps1 False


<syntaxhighlight lang='bash'>
<!-- If you need python libraries that are not installed in the shared environment:
$ conda config --set changeps1 False
 
</syntaxhighlight>
$ pip3 install --user YOURLIBHERE
 
...replacing YOURLIBHERE with the name of the library you need, e.g. 'pandas'. The --user option will install it for just you.
 
If you have a lot of dependencies for a specific project, consider using [[#Python Virtual Environments |Python Virtual Environments]] -->


=== Custom modules ===
=== Custom modules ===
Line 52: Line 59:


==== Installing and making available a custom module ====
==== Installing and making available a custom module ====


{{note}} If you are using <code>screen</code> to run and manage your builds, keep in mind that <code>screen</code> [https://superuser.com/a/235773 drops a few environment variables] such as <code>LD_LIBRARY_PATH</code>, which may mess up your build process. You should check that all the relevant environment variables are set before starting your build.  
{{note}} If you are using <code>screen</code> to run and manage your builds, keep in mind that <code>screen</code> [https://superuser.com/a/235773 drops a few environment variables] such as <code>LD_LIBRARY_PATH</code>, which may mess up your build process. You should check that all the relevant environment variables are set before starting your build.  


The first step toward installing and making available a custom module (in this case, [https://www.jedsoft.org/releases/slang/ slang 2.3.2]) is to spin up the build node, download slang, compile it with a specific prefix, and install it.
 
The first step toward installing and making available a custom module (in this case, R 3.5.0) is to spin up the build node, download R, compile it with a specific prefix, and install it.


<source lang='bash'>
<source lang='bash'>
$ build_machine
$ build_machine
$ wget https://www.jedsoft.org/releases/slang/slang-2.3.2.tar.bz2
$ module load contrib/texlive/2017  # loads the texlive module that is helpful for generating R documentation
$ tar jxvf slang-2.3.2.tar.bz2
$ module load contrib/openblas/0.2.20  # loads the openblas library, which speeds up some R operations significantly
$ cd slang-2.3.2
$ wget https://cran.r-project.org/src/base/R-3/R-3.5.0.tar.gz
$ ./configure --prefix=/gscratch/comdata/modules/sw/slang/2.3.2
$ tar xzvf R-3.5.0.tar.gz
$ cd R-3.5.0
$ ./configure --prefix=/gscratch/comdata/modules/sw/R/3.5.0  --without-x --enable-R-shlib --with-lapack --with-blas="-L/sw/contrib/openblas/0.2.20/lib -lopenblas"
$ make
$ make
$ make install
$ make install
</source>
</source>


The <code>--prefix</code> option to <code>./configure</code> tells the build scripts that slang is going to be installed in <code>/gscratch/comdata/modules/sw/R/3.5.0</code>. This follows a convention that we picked—software in modules should go into <code>/gscratch/comdata/modules/sw/{SOFTWARE_NAME}/{SOFTWARE_VERSION}</code>. The <code>--prefix</code> option is the most important flag for <code>./configure</code>—any other flag or option will be specific to the software being installed.
The <code>--prefix</code> option to <code>./configure</code> tells the build scripts that R is going to be installed in <code>/gscratch/comdata/modules/sw/R/3.5.0</code>. This follows a convention that we picked—software in modules should go into <code>/gscratch/comdata/modules/sw/{SOFTWARE_NAME}/{SOFTWARE_VERSION}</code>. The <code>--prefix</code> option is the most important flag for <code>./configure</code>—any other flag or option will be specific to the software being installed.


The second step is to write a <code>modulefile</code>. This contains the metadata about our module. Edit the file <code>/gscratch/comdata/modules/modulefiles/slang/2.3.2</code> to contain the following
The second step is to write a <code>modulefile</code>. This contains the metadata about our module. Edit the file <code>/gscratch/comdata/modules/modulefiles/R/3.5.0</code> to contain the following


<source lang='tcl'>
<source lang='tcl'>
Line 75: Line 86:
##
##
proc ModulesHelp { } {
proc ModulesHelp { } {
         puts stderr "\tModule providing slang 2.3.2"
         puts stderr "\tModule providing R 3.5.0."
}
}


module-whatis "Module providing slang 2.3.2"
module-whatis "Module providing R 3.5.0."
 
module load contrib/openblas/0.2.20
prepend-path    PATH            /gscratch/comdata/modules/sw/R/3.5.0/bin
prepend-path    MANPATH        /gscratch/comdata/modules/sw/R/3.5.0/share/man
 
# The following line prevents everyone from installing libraries in the global namespace
file mkdir ~/R/x86_64-pc-linux-gnu-library/3.5


prepend-path    PATH            /gscratch/comdata/modules/sw/slang/2.3.2/bin
prepend-path    MANPATH        /gscratch/comdata/modules/sw/slang/2.3.2/share/man
prepend-path    LD_LIBRARY_PATH /gscratch/comdata/modules/sw/slang/2.3.2/lib
prepend-path    PKG_CONFIG_PATH /gscratch/comdata/modules/sw/slang/2.3.2/lib/pkgconfig
</source>
</source>


Note that the filename follows a similar convention as <code>--prefix</code> earlier (<code>/gscratch/comdata/modules/modulefiles/{SOFTWARE_NAME}/{SOFTWARE_VERSION}</code>). This file sets up the <code>PATH</code>, <code>MANPATH</code>, <code>LD_LIBRARY_PATH</code>, and <code>PKG_CONFIG_PATH</code>, environment variables appropriately so that the specified version of slang can be accessed and run as needed. There are many more directives that can go into the <code>modulefile</code>—see <code>man modulefile</code> for details on those directives. If your program is a simple binary, you will likely only need to append to the <code>PATH</code>, and <code>MANPATH</code> environment variables.
Note that the filename follows a similar convention as <code>--prefix</code> earlier (<code>/gscratch/comdata/modules/modulefiles/{SOFTWARE_NAME}/{SOFTWARE_VERSION}</code>). This file sets up the <code>PATH</code> and <code>MANPATH</code> environment variables appropriately so that the specified version of R can be accessed and run as needed. There are many more directives that can go into the <code>modulefile</code>—see <code>man modulefile</code> for details on those directives.


Once this file is written out, the <code>module avail</code> command should list <code>slang/2.3.2</code> as an available module. This is because the module system is set up to look inside <code>/gscratch/comdata/modules/modulefiles</code> for module files, thanks to the <code>MODULEPATH</code> variable that is set through <code>.bashrc</code>. The command <code>module load slang/2.3.2</code> should make slang available and ready for use. To avoid running <code>module load slang/2.3.2</code> whenever you log in, you can add the command at the end of your <code>.bashrc</code> file (after the section that sets <code>MODULEPATH</code>).
Once this file is written out, the <code>module avail</code> command should list <code>R/3.5.0</code> as an available module. This is because the module system is set up to look inside <code>/gscratch/comdata/modules/modulefiles</code> for module files, thanks to the <code>MODULEPATH</code> variable that is set through <code>.bashrc</code>. The command <code>module load R/3.5.0</code> should make R available and ready for use. To avoid running <code>module load R/3.5.0</code> whenever you log in, you can add the command at the end of your <code>.bashrc</code> file (after the section that sets <code>MODULEPATH</code>).
Please note that all contributions to CommunityData are considered to be released under the Attribution-Share Alike 3.0 Unported (see CommunityData:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel Editing help (opens in new window)

Template used on this page: