Requested feature
Easy configuration of IMAS working environment through setting up a predefined set of IMAS libraries
...
Code Block |
---|
module load imasenv/<compiler_vendor> e.g: module load imasenv/intel |
Libraries / modules to be set:
Code Block |
---|
********************************************** GROUP A General purpose tools/libraries, compilers Dependency: NONE ********************************************** * intel * gcc * intelmpi * g95 * java * python * matlab * netbeans * maven * scripts * itmtools * totalview * cmake * mdsplus * blitz * jaxfront ********************************************** GROUP B General purpose tools/libraries Dependency: compilers (group A) ********************************************** * hdf5 * blas * lapack * fftw * pspline * slatec * mkl * matheval * netcdf ********************************************** GROUP C General purpose tools/libraries Dependency: compilers (group A), third parties libraries (group B) Data Dictionary ********************************************** * imas ********************************************** GROUP D General purpose tools/libraries Dependency: compilers (group A), third parties libraries (group B) Data Dictionary, imas (group C) ********************************************** * interpos * fc2k * kepler * idstools * pyual * libbds (imas dependency should be removed) * xmllib (imas dependency should be removed) |
...
versions (compilers), engine (imas) etc) to define the users environment.
Analyzed solutions
Warning |
---|
Please keep in mind a "module" mechanism limitations: among the other, "module" doesn't allow to skip the begin or the middle of module name. Only the "tail" of module name can be skipped (defaulted) So, e.g.module load exampleModule/1.0/requiredLib/2.0 cannot be called like module load exampleModule/requiredLib/2.0, but module load This feature influenced solutions described below. |
A) "Rolling module"
Code Block | ||
---|---|---|
| ||
module load imasenv/intel/3.19.1/ |
Easy to remember and use syntax
Extreme inflexibility - no versions of compiler, UAL engine, etc can be specified (only defaults are used - it is not possible to set e.g. intel/12 instead 17, mdsplus 7.x instead 6.y, etc)
Problems with versioning - every upgrade of library will require manual change of module
User is not aware of changes of default versions ( potential errors: "it worked yesterday"
)
B) Descriptive but enormously long/strange module name
Code Block | ||
---|---|---|
| ||
module load imasenv/ń/libs/3.0/imas/3.19.1/ual/3.8.2/imaslibs/4.0 |
...
Full flexibility of setting versions
Setting up IMAS environment
To overcome disadvantages of solutions presented above, and keep a desired level of flexibility, user working environment can be set by two (meta)modules
Module imaslibs
Code Block | ||
---|---|---|
| ||
imaslibs/<compiler_vendor>/<compiler_version>/<version of this module> e.g. imaslibs[/intel/17.0/1.0] <= part in brackets can be skipped to use defaults |
...
- Compiler
(e.g. intel/17.0
) - All components independent from IMAS/Data Dictionary (group B) , gathered together as a set of modules. Such set of modules will have its own version (e.g.
1.0
)
Module imasenv
Code Block |
---|
imasenv/<imas_ver>/ual/<engine_ver>/<version of this module> e.g. imasenv[/3.19.1/ual/3.8.2/1.0] <= part in brackets can be skipped to use defaults |
...