Environment modules - Revision history

import>Jss43: /* python */

2008-07-12T00:44:35Z

python

← Older revision		Revision as of 00:44, 12 July 2008
Line 32:		Line 32:
	=== python ===		=== python ===

	Similarly to bash, in /usr/share/modules/init there is a python script to initialise the module system. It doesn't work due to a bug in modules' auto-configuration causes an incorrect path to be set. A correct version can be downloaded [[Media:Python_modules.txt \| here]]---save it as python_modules.py. (This annoying bug is going to be fixed in the SuSE 10.3 image --[[User:cen1001\|Catherine]] 16:30, 9 July 2008 (BST)) You can initialise modules using either ''execfile'' (specifying the full path) or ''import'' (where it must be in the current directory or in your PYTHONPATH, and the .py is left out of the module name). ''module('command')'' then works, where command is one of the usual module commands we use in the terminal.		Similarly to bash, in /usr/share/modules/init there is a python script to initialise the module system. It doesn't work due to a bug in modules' auto-configuration causes an incorrect path to be set. A correct version can be downloaded [[Media:Python_modules.txt \| here]]---save it as python_modules.py. (This annoying bug is going to be fixed in the SuSE 10.3 image --[[User:cen1001\|Catherine]] 16:30, 9 July 2008 (BST)) You can initialise modules using either ''execfile'' (specifying the full path) or ''import'' (where it must be in the current directory or in your PYTHONPATH, and the .py is left out of the python module name). ''module('command')'' then works, where command is one of the usual module commands we use in the terminal.

	<pre>		<pre>
Line 54:		Line 54:
	in the main() subroutine.		in the main() subroutine.

	You now have the module command defined in ipython which can be used exactly as in bash:		You now have the module command defined in ipython which can be used in exactly the same way as in bash:
	<pre>		<pre>
	jss43@keiko:~> ipython		jss43@keiko:~> ipython

import>Cen1001: /* Private modules */

2008-07-09T15:36:39Z

Private modules

← Older revision		Revision as of 15:36, 9 July 2008
Line 118:		Line 118:

	It is important to prepend the paths: earlier versions of gcc and gfortran exist on the system PATH already, so we must make the shell find the user-installed gcc-4.2 suite first.		It is important to prepend the paths: earlier versions of gcc and gfortran exist on the system PATH already, so we must make the shell find the user-installed gcc-4.2 suite first.

			If you want to make private modulefiles for libraries it may be useful to know that the local compilers have been wrapped to honour the variables LIBRARY_PATH and CPATH . LIBRARY_PATH is treated as a list of directories to search for libraries when linking, and CPATH is a list of directories to search for header files. The contents of LIBRARY_PATH are also passed to the linker as the runpath setting for the resulting binary. This means you can do away with -L and -I options when compiling, and the runpath thing means you can often (but not always) get away without resorting to setting LD_LIBRARY_PATH .

	=== lapack ===		=== lapack ===

import>Cen1001: /* python */

2008-07-09T15:30:07Z

python

← Older revision		Revision as of 15:30, 9 July 2008
Line 32:		Line 32:
	=== python ===		=== python ===

	Similarly to bash, in /usr/share/modules/init there is a python script to initialise the module system. It doesn't work due to a bug in modules' auto-configuration causes an incorrect path to be set. A correct version can be downloaded [[Media:Python_modules.txt \| here]]---save it as python_modules.py. You can initialise modules using either ''execfile'' (specifying the full path) or ''import'' (where it must be in the current directory or in your PYTHONPATH, and the .py is left out of the module name). ''module('command')'' then works, where command is one of the usual module commands we use in the terminal.		Similarly to bash, in /usr/share/modules/init there is a python script to initialise the module system. It doesn't work due to a bug in modules' auto-configuration causes an incorrect path to be set. A correct version can be downloaded [[Media:Python_modules.txt \| here]]---save it as python_modules.py. (This annoying bug is going to be fixed in the SuSE 10.3 image --[[User:cen1001\|Catherine]] 16:30, 9 July 2008 (BST)) You can initialise modules using either ''execfile'' (specifying the full path) or ''import'' (where it must be in the current directory or in your PYTHONPATH, and the .py is left out of the module name). ''module('command')'' then works, where command is one of the usual module commands we use in the terminal.

	<pre>		<pre>

import>Jss43: /* python */

2008-07-06T00:24:30Z

python

← Older revision		Revision as of 00:24, 6 July 2008
Line 56:		Line 56:
	You now have the module command defined in ipython which can be used exactly as in bash:		You now have the module command defined in ipython which can be used exactly as in bash:
	<pre>		<pre>
	jss43@keiko:~> ipython		jss43@keiko:~> ipython
	Python 2.5 (r25:51908, Jan 10 2008, 18:01:52)		Python 2.5 (r25:51908, Jan 10 2008, 18:01:52)
	Type "copyright", "credits" or "license" for more information.		Type "copyright", "credits" or "license" for more information.

import>Jss43: /* lapack */

2008-07-06T00:24:02Z

lapack

← Older revision		Revision as of 00:24, 6 July 2008
Line 148:		Line 148:
	prepend-path LIBRARY_PATH $root		prepend-path LIBRARY_PATH $root
	prepend-path LD_LIBRARY_PATH $root		prepend-path LD_LIBRARY_PATH $root
	prepend-path MANPATH $root/manpages/ma		prepend-path MANPATH $root/manpages/man
	</pre>		</pre>

import>Jss43: /* Private modules */

2008-07-05T23:35:10Z

Private modules

@@ Line 149: / Line 149: @@
 prepend-path LD_LIBRARY_PATH $root
 prepend-path MANPATH $root/manpages/ma
 </pre>

import>Jss43: /* Private modules */

2008-07-05T19:06:01Z

Private modules

← Older revision		Revision as of 19:06, 5 July 2008
Line 84:		Line 84:
	My private modules can be used exactly as the standard modules.		My private modules can be used exactly as the standard modules.

	Module configuration files are in Tcl, but we can avoid knowing anything about Tcl by shamelessly copying the existing module files (in usr/local/shared/Modules/modulefiles). As an example, here are two module files I have:		Module configuration files are in Tcl, but we can avoid knowing anything about Tcl by shamelessly copying the existing module files (in /usr/local/shared/Modules/modulefiles). As an example, here are two module files I have:

	=== gcc-4.2 ===		=== gcc-4.2 ===

import>Jss43: Enviroment modules moved to Environment modules

2008-07-05T19:03:50Z

Enviroment modules moved to Environment modules

← Older revision	Revision as of 19:03, 5 July 2008
(No difference)

import>Jss43: /* Private modules */

2008-07-05T19:03:27Z

Private modules

← Older revision		Revision as of 19:03, 5 July 2008
Line 73:		Line 73:
	== Private modules ==		== Private modules ==

			It is possible to extend the module system by creating your own modules. First of all do ''module load use.own''. The directory ~/privatemodules is created the first time you do this. ~/privatemodules also contains a template (null) from which you can create module configuration files. If you do ''module avail'' after loading the use.own module, you'll see there's a new section: /home/${USER}/privatemodules. This contains any modules you create.
⚫	=== ~~gfortran~~ ===

			<pre>
			jss43@keiko:~> module avail
			[...]
			-------------------------- /home/jss43/privatemodules --------------------------
			gcc-4.2 lapack-64
			</pre>

			My private modules can be used exactly as the standard modules.

			Module configuration files are in Tcl, but we can avoid knowing anything about Tcl by shamelessly copying the existing module files (in usr/local/shared/Modules/modulefiles). As an example, here are two module files I have:

		⚫	=== gcc-4.2 ===

			Following on from the installation process described [[Fortran_issues#gfortran \| here]]. I based this on the g95 module file.
			<pre>
			#%Module1.0#####################################################################
			##
			##
			##

			set base "/home/jss43/src/gcc-4.2"
			set version "4.2"
			set compilerhome $base

			proc ModulesHelp { } {
			global compilerhome
			global version
			puts stderr "\tgcc - loads version $version of the gcc compiler suite."
			puts stderr "\tTHIS VERSION USES A 64-BIT INTEGER"
			puts stderr "\tThis adds $compilerhome/bin to the PATH"
			puts stderr "\n\tgcc contains free c and F95 compilers."
			puts stderr "\tThere are extensive man and info pages."
			}

			module-whatis "Loads version $version of the gcc compiler"

			prepend-path PATH $compilerhome/bin
			prepend-path LD_LIBRARY_PATH $compilerhome/lib64
			prepend-path MANPATH $compilerhome/man
			prepend-path INFOPATH $compilerhome/info
			</pre>

			It is important to prepend the paths: earlier versions of gcc and gfortran exist on the system PATH already, so we must make the shell find the user-installed gcc-4.2 suite first.

	=== lapack ===		=== lapack ===

			Following on from the installation process described [[Lapack compilation \| here]]. I based this on the atlas/32/P4SSE2 module file.

			<pre>
			#%Module1.0#####################################################################
			##
			##
			##

			conflict atlas acml

			set root /home/jss43/src/lib/lapack-3.1.1
			set version 3.1.1

			proc ModulesHelp { } {
			global root
			puts stderr "\t[module-info name] - loads ATLAS maths library"
			puts stderr "\tThis is a well-known linear algebra library."
			puts stderr "\tThis version was compiled locally using the"
			puts stderr "\tdefault options."
			puts stderr "\tFor documentation see the homepage:"
			puts stderr "\thttp://math-atlas.sourceforge.net/"
			}

			module-whatis "Loads version $version of the lapack library"

			prepend-path LIBRARY_PATH $root
			prepend-path LD_LIBRARY_PATH $root
			prepend-path MANPATH $root/manpages/ma
			</pre>

import>Jss43: /* python */ correct filenames

2008-07-05T16:30:32Z

python: correct filenames

← Older revision		Revision as of 16:30, 5 July 2008
Line 48:		Line 48:

	If you use ipython (if you don't, you should), then you can implement the module commands as a "magic" command (type ''magic'' at the ipython prompt). The script needed is [[Media:Modules_magic.txt \| here]]---save it to ~/.ipython/modules_magic.py. You can add it to the standard profile (ipythonrc):		If you use ipython (if you don't, you should), then you can implement the module commands as a "magic" command (type ''magic'' at the ipython prompt). The script needed is [[Media:Modules_magic.txt \| here]]---save it to ~/.ipython/modules_magic.py. You can add it to the standard profile (ipythonrc):
	<pre>execfile ~/.ipython/~~python_modules~~.py</pre>		<pre>execfile ~/.ipython/modules_magic.py</pre>

	If you are using a later version of ipython, then there will be a ipy_user_conf.py file in your .ipython directory. To implement the module magic command in this case, add		If you are using a later version of ipython, then there will be a ipy_user_conf.py file in your .ipython directory. To implement the module magic command in this case, add
	<pre>import_all("~~python_modules~~")</pre>		<pre>import_all("modules_magic")</pre>
	in the main() subroutine.		in the main() subroutine.