Versions Compared

Old Version 20

changes.mady.by.user Bartosz Palak

Saved on

compared with

New Version 21

changes.mady.by.user Bartosz Palak

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

This document provides a short description of proposed solution. For a more detailed analysis look >>HERE<<

Table of Contents

  

Table of Contents

Objectives

Info
iconfalse
titleRequested 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

 

 

Libraries / modules to be set:

Code Block
**********************************************
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)
* amns

 

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

Analyzed solutions

Warning

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.

A)  "Rolling module"

Code Block
titleExemplary call
 module load imasenv/intel/3.19.1/

...

B)  Descriptive but enormously long/strange module name

Code Block
titleExemplary 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

Setting up IMAS environment

...

environment

...

Module imaslibs

Code Block
titleModule 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

...