Quickstart

To fully configure your working IMAS environment you have to load two modules:

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 imasenvwpcdenv[/<compiler_vendor>
e.g: /<compiler_version>/<version of this module>]
module load imasenv/intel

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.

Analyzed solutions

A)  "Rolling module"

 module load imasenv/intel/3.19.1/ 

...

B)  Descriptive but enormously long/strange module name

...

[/<imas_ver>/ual/<engine_ver>/<version of this module>]

part in brackets [] can be skipped to use defaults

...

Module wpcdenv

Loading libraries/tools not depending on IMAS/DD

wpcdenv/<compiler_vendor>/<compiler_version>/<version of this module>
e.g. wpcdenv[/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, gathered together as a set of modules. Such set of modules will have its own version (e.g. 1.0 )

Module imasenv

Loading libraries/tools depending on IMAS/DD

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, gathered together as a set of modules. Such set of modules will have its own version (e.g. 1.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

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)