Modules<\/em> is the system by which most software is made available. Modules allow, via a simple interface, the update of various paths (and other environment settings) that allow access to software. <\/p>\n The use of modules also provides a convenient way to switch between different versions of the same software (such as compilers). <\/p>\n The environment is controlled using the module command with various arguments: <\/p>\n The software available of the CSF has been placed in categories:<\/p>\n The To use a module\/piece of software:<\/p>\n For example:<\/p>\n It is possible, and often necessary, to have multiple modules loaded at once. For example the following commands are equivalent:<\/p>\n or<\/p>\n Some modulefiles have restricted access (you need to be in a certain unix group to load the modulefile). The module commands may report an error when trying to access these modules if you don’t have permission to use them. For example The module paths on the CSF are lengthy, but you can use bash completion to help you. Press Modulefiles can be loaded:<\/p>\n There are pros and cons to each method but which method you choose is up to you – both are valid.<\/p>\n The advantages of loading the modulefile on the login node before<\/em> you submit the job are that you can check the name of the modulefile is correct (any spelling mistakes and the modulefile won’t be loaded). You could also check the settings the modulefile makes (e.g., an environment variable) and then use that in your jobscript. The disadvantages are that the particular modulefile name used is not recorded in your jobscript. If you wish to run the job again (perhaps in a few months time) you may have forgotten which version of a modulefile you used.<\/p>\n The advantages of loading the modulefile in the jobscript are that the names of the modulefiles are recorded – this helps with reproducibility. However, if you spell a modulefile name incorrectly the mistake will only be detected when the job runs. Your job will probably fail and you’ll have to resubmit the job, waiting in the queue again.<\/p>\n If you prefer to load your modulefiles on the login node before<\/em> you submit a job then you should add the following line to your jobscript:<\/p>\n Note: That is an uppercase V.<\/p>\n The batch system takes a copy of your environment at the time at which you run<\/em> the If you prefer to load your modules within the batch script you must start the batch script with the following line:<\/p>\n You can then do the usual jobscript commands and also include module commands. For example:<\/p>\n We no longer use Note: We recommend that you only load modulefiles as and when you require them, not automatically on login. This way you avoid unexpected software clashes, interactions and environment problems that can cause job failure.<\/p>\n If you do wish to always have certain modulefiles loaded when you log into the CSF then best practice is to specify them in your If you have installed a piece of software in your home directory then you can create your own modulefile for it which saves you having to set variables on the command line, in your Overview Modules is the system by which most software is made available. Modules allow, via a simple interface, the update of various paths (and other environment settings) that allow access to software. The use of modules also provides a convenient way to switch between different versions of the same software (such as compilers). Commands The environment is controlled using the module command with various arguments: module list – lists currently loaded modules module avail –.. Read more »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":8,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-51","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/pages\/51","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/comments?post=51"}],"version-history":[{"count":20,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/pages\/51\/revisions"}],"predecessor-version":[{"id":3781,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/pages\/51\/revisions\/3781"}],"up":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/pages\/8"}],"wp:attachment":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf-apps\/wp-json\/wp\/v2\/media?parent=51"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Commands<\/h2>\n
\n
module list<\/code> – lists currently loaded modules<\/li>\nmodule avail<\/code> – lists all available modules<\/li>\nmodule load modulename<\/em><\/code> – loads module modulename<\/em><\/li>\nmodule unload modulename<\/em><\/code> – unloads module modulename<\/em><\/li>\nmodule switch oldmodulename<\/em> newmodulename<\/em><\/code> – switches between two modules<\/li>\nmodule initadd modulename<\/em><\/code> – run this command once to automatically ensure that a module is loaded when you log in. (It creates a .modules<\/code> file in your home dir which acts as your personal configuration.)<\/li>\nmodule purge<\/code> – unload all modules<\/li>\nmodule help<\/code> – may show longer description of the module if present in the modulefile<\/li>\nman module<\/code> – detailed explanation of the above commands and others<\/li>\n<\/ul>\nCategories<\/h2>\n
\n
module avail<\/code> command will list everything available. You can view a single category at a time with:<\/p>\n\r\nmodule avail <category>\r\n #\r\n # replacing the optional <category> with one of the above\r\n<\/pre>\n
\r\nmodule load <module name>\r\n #\r\n # replacing <module name> with the module you want\r\n<\/pre>\n
\r\nmodule load compilers\/intel\/fortran\/11.1.064\r\n<\/pre>\n
\r\nmodule load tools\/gcc\/autoconf\/2.68\r\nmodule load tools\/gcc\/cmake\/2.8.7\r\n<\/pre>\n
module load tools\/gcc\/autoconf\/2.68 tools\/gcc\/cmake\/2.8.7<\/pre>\n
module avail<\/code> will complain about not being able to read certain modulefiles. You can simply ignore these errors. For example:<\/p>\n\r\n[mxyzabc2@login2 ~]$ module avail apps\r\nutility.c(2229):ERROR:50: Cannot open file '\/opt\/gridware\/modulefiles\/apps\/binapps\/starccm\/7.04' for 'reading'\r\n---------------------- \/opt\/gridware\/modulefiles ---------------------\r\napps\/amd-4.5.2\/Code_Saturne\/2.0.6 apps\/gcc\/ipython\/0.13.2\r\napps\/amd-4.5.2\/Code_Saturne\/2.3.1 apps\/gcc\/lens\/2.64\r\napps\/amd-4.5.2\/Gerris\/13.01.12 apps\/gcc\/octave\/3.6.4\r\n #\r\n # indicates the we are not in the unix group for the starccm software but we\r\n # simply ignore this error and can see all of the modulefiles available to us\r\n #\r\n<\/pre>\n
Bash Completion<\/h2>\n
TAB<\/code> part-way through typing a module name and the name will be completed for you or a list of possible completions will be given. Type a few more characters and hit TAB<\/code> again to narrow the list down until you get the full module name.<\/p>\nSeeing module environment settings in batch<\/h2>\n
\n
Loading modulefiles on the login node<\/h3>\n
\r\n#$ -V # Inherit settings from the login node\r\n<\/pre>\n
qsub<\/code> command, not when your job eventually runs. This means that after submitting your job with qsub<\/code> you are free to change your environment or even log out and your job will still see the correct environment when it runs.<\/p>\nLoading modulefiles in jobscripts<\/h3>\n
\r\n#!\/bin\/bash --login\r\n<\/pre>\n
\r\n#!\/bin\/bash --login\r\n#$ -cwd # Run from the current directory\r\n # Notice there is no<\/strong> #$ -V flag now!!\r\n\r\nmodule load compilers\/intel\/c\/12.0.5\r\n.\/my_app\r\n<\/pre>\n
#$ -V<\/code> to inherit the environment because we are loading modulefiles in the jobscript to set up the environment, so it should be removed from your jobscript if you have been using it previously.<\/p>\nAutomatically loading modulefiles on log in<\/h2>\n
.modules<\/code> environment file, not the .bashrc<\/code>, or .bash_profile<\/code>. Add the module load<\/code> commands to the end of the .modules<\/code> file and leave any other content in that file untouched. However, bear in mind that the warning above still applies.<\/p>\nPrivate modules – software you have installed<\/h2>\n
.bashrc<\/code>, .bash_profile<\/code> or in batch scripts.<\/p>\n\n
\r\nmkdir ~\/privatemodules\r\n<\/pre>\n<\/li>\n
\r\ncd ~\/privatemodules\r\npwd\r\n\/mnt\/iusers01\/xy01\/mxyzabc2\/privatemodules\r\n\r\n# Create a directory named after my own application\r\nmkdir myapp\r\n\r\n# Go in to the dir and create a text file named using the application version number (e.g., 2.03):\r\ncd myapp\r\ngedit 2.03\r\n #\r\n # Write your modulefile in this plain text file which is named '2.03'\r\n # It is an unusual name for a text file but Linux allows any name to be used.\r\n # It will make the 'module load' command used later look like the others on the CSF.\r\n # See below for a template modulefile\r\n\r\n# You should now have a file in at the following location:\r\n~\/privatemodules\/myapp\/2.03 \r\n<\/pre>\n<\/li>\n
\r\nmodule load use.own\r\nmodule load myapp\/2.03\r\n<\/pre>\n<\/li>\n<\/ul>\n
A template for a modulefile<\/h3>\n
\r\n#%Module1.0####################################################\r\n##\r\n## APP Modulefile\r\n## -- Replace APP with the name of your app\r\n##\r\nproc getenv {key {defaultvalue {}}} {\r\n global env; expr {[info exist env($key)]?$env($key):$defaultvalue}\r\n}\r\n\r\n## -- The 'module load' line below shoud be where you specify other modulefiles that may be required\r\n## -- Remove the 'module load' line if you do not need it\r\n## -- For example, compliers you used to build the software and mpi\r\nmodule load compilers\/gcc\/x.x.x mpi\/gcc\/openmpi\/1.x.x\r\n\r\n## -- Now, specify the path to the top level of your software install and set that variable\r\nset APP_DIR \/PATH\/TO\/SOFTWARE_ROOT\/\r\nsetenv APP_DIR $APP_DIR\r\n\r\n## -- Next add required environment variables as detailed in the software manual\r\n## -- Note, no need for 'export', the below examples add to your existing environment\r\nprepend-path PATH $APP_DIR\/bin\r\nprepend-path\tLD_LIBRARY_PATH $APP_DIR\/lib\r\n<\/pre>\nFurther Information<\/h2>\n
\n