You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

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. 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
(plus EUROfusion/IMAS libs and tools that NOT DEPEND on Data Dictionary)
 Dependency: compilers (group A)
**********************************************
* hdf5
* blas
* lapack
* fftw
* pspline
* slatec
* mkl
* matheval
* netcdf

**********************************************
GROUP C
IMAS (UAL) library
Dependency: compilers (group A), third parties libraries (group B)
			Data Dictionary
**********************************************
* imas

**********************************************
GROUP D
EUROfusion/IMAS libs and tools that DEPEND on Data Dictionary/UAL
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)

 

3. Factors defining user working environment

  1. Compiler, defined by:
    1. Vendor  (e.g. Intel, GNU, ....)
    2. Version (e.g. 17.0, 6.1.0 , ...)
  2. Versions of libraries that NOT depend on IMAS/Data dictionary
    1. For sake of simplicity, libraries are grouped in one "set"
    2. Set of libraries has its own version
  3. IMAS (UAL), defined by:
    1. Data Dictionary version (e.g. 3.19.1, 3.20.0,....)
    2. UAL engine version (e.g. 3.8.3, ...)
  4. Versions of libraries that depend on IMAS/Data dictionary
    1. For sake of simplicity, libraries are grouped in one "set"
    2. Set of libraries has its own version

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. module load exampleModule/1.0/requiredLib/2.0 cannot be called like module load exampleModule/requiredLib/2.0, but module load exampleModule/1.0 or just module load exampleModule is OK

This feature influenced solutions described below.

4.1. A)  "Rolling module"

Exemplary call
 module load imasenv/intel/3.19.1/ 
  • (plus) Easy to remember and use syntax
  • (minus) Extreme inflexibility - no versions of compiler, UAL engine, etc can be specified (only defaults are used - it is not possible to set e.g. intel/12 instead 17, mdsplus 7.x instead  6.y, etc)
  • (minus)Problems with versioning  - every upgrade of library will require manual change of module
  • (minus) User is not aware of changes of default versions ( potential errors: "it worked yesterday" (smile) )

4.2. B)  Descriptive but enormously long/strange module name

Exemplary call
module load imasenv/ń/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

(minus) (minus) Main disadvantage is rather obvious (smile) It would be really annoying  to use such long name... Potential simplifications (like parsing module name) are possible rather theoretically

(plus) 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 (warning)

5.1. Module imaslibs

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

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:

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

 

Using default versions

The end ("tail") of module name can be skipped to use default versions, so:

  • module load imaslibs/intel/17.0/1.0  is equal to
    • module load imaslibs/intel/17.0  (assuming 1.0 as default version of set of libs)
    • module load imaslibs/intel        (assuming intel/17.0/ as default version of compiler)
    • module load imaslibs              (assuming intel as default compiler)

 

  • module load imasenv/3.19.1/ual/3.8.2/1.0 is equal to
    • module load imasenv/3.19.1/ual/3.8.2 (assuming 1.0 as default version of set of IMAS libs)
    • module load imasenv/3.19.1                      (assuming 3.8.2 as default version of UAL)
    • module load imasenv                            (assuming 3.19.1 as default version of Data Dictionary)



 

 

 

  • No labels