Bureaucrats, cc_docs_admin, cc_staff, rsnt_translations
2,807
edits
No edit summary |
No edit summary |
||
Line 96: | Line 96: | ||
The inconvenience of using a module hierarchy is that, since modules can have the same name, only the modules that are compatible with the "parent" modules are displayed by the <code>module avail</code> command. Loading a parent module is therefore a prerequisite to loading some modules. To get complete information, the module system provides the <code>module spider</code> command. It scans the entire hierarchy and displays all the modules. By specifying a module and a particular version, it is then possible to see which paths in the hierarchy enable the desired module to be loaded. | The inconvenience of using a module hierarchy is that, since modules can have the same name, only the modules that are compatible with the "parent" modules are displayed by the <code>module avail</code> command. Loading a parent module is therefore a prerequisite to loading some modules. To get complete information, the module system provides the <code>module spider</code> command. It scans the entire hierarchy and displays all the modules. By specifying a module and a particular version, it is then possible to see which paths in the hierarchy enable the desired module to be loaded. | ||
= Automatic replacement of modules = | |||
When the module system detects two modules of the same family, or two version of the same module, the command <code>module load</code> will automatically replace the original module with the one to be loaded. In the cases where the replaced module is a node in the module hierarchy, dependent modules will be reloaded if there are compatible versions, or deactivated otherwise. | |||
When | |||
= Creating modules = | = Creating modules = |