1. Requested feature
Easy configuration of IMAS working environment through setting up a predefined set of IMAS libraries
using simple call of the module imasenv
:
module load imasenv/<compiler_vendor> e.g: module load imasenv/intel
2.
3. Libraries / modules to be set:
********************************************** 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)
Please notice, that beside dependencies mentioned above, some other factors should be considered, (e.g.
versions (compilers), engine (imas) etc) to define the users environment.
4. Analyzed solutions
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. exampleModule/1.0/requiredLib/2.0
cannot be called like exampleModule/requiredLib/2.0 (but
exampleModule/1.0
is OK
This feature influenced solutions described below.
4.1. A) "Rolling module"
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 intel/12 instead 17, mdsplus 7.x instead 6.y)
Problems with versioning - every upgrade of library will require manual change of module
Changes of default versions hidden from the user ( potential errors "it worked yesterday"
)
4.2. B) Descriptive but enormously long/strange module name
module load imasenv/intel/3.17/libs/3.0/imas/3.19.1/ual/3.8.2/imaslibs/4.0
- Module
libs
will set up modules fromgroup A
andgroup B
- Module
imaslibs
will set up modules fromgroup D
Main disadvantage is rather obvious
It would be really annoying to use such long name... Potential simplifications (like parsing module name) are possible rather theoretically
Full flexibility of setting versions
C) Two modules to set environment
Solution C) Multiplication of modules
Environment configured by loading 4 modules.
module load intel[/12]
module load libs[/x.y]
module load imas[3.19.1/ual/3.8.2]
module load imasenv[/x.y]
As you can see - this solution is simplest, most configurable (versions can be specified or skipped to use defaults), every "factor" can be versioned
but.... 4 modules?
Waiting for your suggestions
Bartek
Solution C1 [simplification of C]
Only two modules
Module 1)
imaslibs/<comp_vendor>/<comp_ver>/<version of this module>
imaslibs[/intel/17.0/1.0]
Module will load compiler plus third parties libraries gathered in some set (ver 1.0)
imasenv/<imas_ver>/ual/<eng_ver>/<version of this module>
e.g.
imasenv[/3.19.1/ual/3.8.2/1.0]
Module will load imas plus EF/IMAS libs gathered in some set (ver 1.0)