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:

* intel
* gcc
* intelmpi
* g95
* java
* python
* matlab
* netbeans
* maven
* scripts
* itmtools
* totalview
* cmake
* hdf5
* mdsplus
* blitz
* interpos
* pspline
* slatec
* blas
* lapack
* mkl
* matheval
* netcdf
* fftw
* libbds
* jaxfront
* fc2k
* kepler
* idstools
* pyual

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 (?))

Solution A)  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[/

[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

...

• 3.19.1/

...

*  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

User will be not aware of changes -> potential errors "it worked yesterday"

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]

• 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 will load  imas plus EF/IMAS libs gathered in some set (ver 1.0)