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 |
...