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

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 from group A and group B
• Module imaslibs will set up modules from group 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

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

5.1. Module imaslibs

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

Module will load:

• 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 )

5.2. Module imasenv

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

Module will load:

• imas module  (e.g.imasenv[/3.19.1/ual/3.8.2 )
• All components dependent on IMAS/Data Dictionary (group D), gathered together as a set of modules. Such set of modules will have its own version (e.g. 1.0 )

Presented solution:

• Easy to use by users (to use default versions is enough to write module load imaslibs; module load imasenv)
• Flexibility: Full names can be specified to use non-default versions of library sets