\n\n\r\n#!\/bin\/bash --login<\/strong>\r\n#SBATCH -p partition<\/em>\r\n#SBATCH -t Wallclock<\/em>\r\n\r\nmodule load name\/of\/app\/1.2.3\r\n\r\napp.exe input.dat ....\r\n<\/pre>\n<\/td>\n\n\r\n#!\/bin\/bash\r\n#SBATCH -p partition<\/em>\r\n#SBATCH -t Wallclock<\/em>\r\n\r\n# Settings are inherited from login node so do:\r\n# module load name\/of\/app\/1.2.3<\/em> on the login node\r\n\r\napp.exe input.dat ....\r\n<\/pre>\n<\/td>\n<\/tr>\n\nThe --login<\/code> flag on the first line is needed to make module<\/code> commands work inside jobscripts.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nNote: If loading the modulefile on the login node and inheriting the settings in the jobscript, the batch system takes a copy of your environment at the time at which you run<\/em> the sbatch<\/code> command, not when your job eventually runs. This means that after submitting your job with sbatch<\/code>, you are free to change your environment or even log out and your job will still see the correct environment when it runs. For example:<\/p>\n\r\n# From the CSF3 login node, submit a job to run appA \r\nmodule load name\/of\/appA\/1.2.3\r\nsbatch job_to_run_appA\r\n #\r\n # This takes a copy right now<\/em> of all of the environment\r\n # settings made by appA's modulefile\r\n\r\n# Unload all modules, clear the settings\r\nmodule purge\r\n #\r\n # This does NOT affect the previous job. It has already\r\n # copied all of the required settings. When the job eventually\r\n # runs it will have all of the settings from the appA modulefile.\r\n\r\n# Set up for a different app\r\nmodule load name\/of\/appB\/4.5.6\r\nsbatch job_to_run_appB\r\n #\r\n # This take a copy right now<\/em> of all of the environment\r\n # settings made by appB's modulefile. \r\n\r\n# Even if we log out before the jobs have run, they have a copy\r\n# of all of the settings needed for each job.\r\nlogout\r\n<\/pre>\nAutomatically loading modulefiles on log in<\/h2>\nNote: 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 .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>\nIf 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 .bashrc<\/code>, .bash_profile<\/code> or in batch scripts.<\/p>\n\n- In your home dir create a directory called ‘privatemodules’ (the name is key)\n
mkdir ~\/privatemodules\r\n<\/pre>\n<\/li>\n - Within that dir create the required folders and modulefiles (see template below) so you get something like:\n
cd ~\/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.0.3):\r\ncd myapp\r\ngedit 2.0.3\r\n #\r\n # Write your modulefile in this plain text file which is named '2.0.3'\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.0.3 \r\n<\/pre>\n<\/li>\n - To load your new modulefile first load the ‘use.own’ modulefile (only need to do this once).\n
module load use.own\r\nmodule load myapp\/2.0.3\r\n<\/pre>\n<\/li>\n<\/ul>\n | | |