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

Compare with Current View Page History

« Previous Version 4 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.  

3. 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, 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 (?))

 

Solution A)  Enormously long/strange module name

  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

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]

Module will load  imas plus EF/IMAS libs gathered in some set (ver 1.0)

 

  • No labels