...

**********************************************
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, UAL engine version
**********************************************
* imas

**********************************************
GROUP D
General purpose tools/libraries
Dependency: compilers (group A), third parties libraries (group B)
			Data Dictionary, UAL engine version, imas (group C)
**********************************************
* interpos
* fc2k
* kepler
* idstools
* pyual
* libbds (imas dependency should be removed)
* xmllib (imas dependency should be removed)

Unfortunately it is not so simple, as it may look at the first sight,

as several (main) factors defining environment should be considered:

Factor A : compiler - vendor + version

Factor B : third parties libraries

• general purpose libraries (netCDF, jaxfront)
• libraries requested by UAL (blitz, mdsplus)

Factor C : imas (UAL) - Data Dictionary + engine

Factor D : set of  imas/EF, possibly DD dependent libraries (like XMLLIB, libBDS, AMNS, interpos (?))

...

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.

Analyzed solutions

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

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

[please notice that only "tail" of module name can be shortened/skipped]

Potential simplification - parsing of module name to get info about versions of "factors"

and using defaults if not exists

(results in very complex structure of module, necessity of storing default versions in text files etc)

Solution B) Rolling module

Defaults for some of factors - without versioning

e.g.   imasenv/intel/3.19.1/ will load

*  3.17 for intel

* third parties libs -  loaded in some predefined set

* predefined engine for given UAL

* EF/imas libs - predefined set

Every upgrade of library (like mdsplus now is upgraded) will require manual change of module.

It would be not possible to set intel/12 instead 17, mdsplus 7.x instead  6.y

• 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

C) Two modules to set environmentUser will be not aware of changes -> potential errors "it worked yesterday"

Solution C) Multiplication of modules

...