Bureaucrats, cc_docs_admin, cc_staff, rsnt_translations
2,807
edits
No edit summary |
No edit summary |
||
Line 87: | Line 87: | ||
Some modules are hidden. You may ignore them. They are typically modules that you don't have to load manually. They are loaded automatically based on other modules. | Some modules are hidden. You may ignore them. They are typically modules that you don't have to load manually. They are loaded automatically based on other modules. | ||
= Module hierarchy = | |||
Many HPC clusters around the world use a flat module structure: All modules are at the same level. This becomes problematic when many combinations of versions of different modules are available on a system. For example, if you need to use the [[FFTW]] library and the module <code>fftw</code> is available in several versions, including a version compiled with GCC 9.3 and Open MPI 4.0, you might see modules named <code>openmpi/4.0_gcc9.3</code> and <code>fftw/3.8_gcc9.3_openmpi4.0</code>. This is neither elegant nor practical. To solve this problem we use a hierarchy of modules. Rather than using the command | |||
{{Command|module load gcc/9.3 openmpi/4.0_gcc9.3 fftw/3.8_gcc9.3_openmpi4.0}} | |||
{{Command|module load gcc/ | |||
you instead use | you instead use | ||
{{Command|module load gcc/ | {{Command|module load gcc/9.3 openmpi/4.0 fftw/3.8}} | ||
This is made possible by using a module hierarchy. The <code>fftw/3. | This is made possible by using a module hierarchy. The <code>fftw/3.8</code> module that is loaded will not be the same one that would be loaded if you had previously loaded the Intel compilers instead of GCC. | ||
<div class="mw-translate-fuzzy"> | <div class="mw-translate-fuzzy"> |