Versions Compared

Old Version 9

changes.mady.by.user Bartosz Palak

Saved on

compared with

New Version Current

changes.mady.by.user Bartosz Palak

Saved on

Key

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

Table of Contents

...

Evaluation

Current solution

The initial request was to enable users to set-up working environment easily providing possibility of choosing:

...

  • in most cases users specify only "module load imasenv"  or "module load imasenv/<dd-ver> "
  • UAL is a "yet another library" that don't has to be set separately ("ual/<al-version>" part of schema)
  • users usually don't take into account *AL version* and other libs version... and use defaults 
  • users don't take into account compiler version... and use default one
  • there is a need to couple imasenv with particular wpcdenv version:
    • currently imasenv loads default wpcdenv
    • all imasenv libraries can be not compatible with other wpcdenv version as being used during compilation
    • loading manually wpcdenv by user and than imasenv can result in inconsistent environment 
  • The number of modules is growing very fast (see "module avail imasenv") - it is harder and harder to find a proper version

Thus, there is a need of simplification  of described mechanism and to provide a proper lifecycle !

Simplification of wpcdenv/imasenv schema

Propositions to simplify mechanism for setting working environment base on initial David C. suggestions (yes, Dave, I should follow your hints):

  • to remove "ual/<al-version>" part of imasenv module name
  • to remove "<compiler-version>" part of wpcdenv module name

  • to combine wpcdenv and imasenv within one module 

    Code Block
    imasenv/<dd-ver>/<compiler><compiler_vendor>/<compiler-ver>_version>/<library-set-ver>
e.g.:
imasenv/3.24.0/intel/17.0/1.0.2


...

Info

Defaults

Please note that module system allows to provide defaults on every level of module structure . So, taking - a "tail" of module name can be skipped to use default versions. 

Taking imasenv as an example there is :

  • default DD for module imasenv  
  • default UAL for module imasenv/<DD_ver> 
  • default set of submodules for module imasenv/<DD_ver>/ual/<UAL_ver> 

    • , following calls loads the same module :

    • module load imasenv
    • module load imasenv/3.24.0
    • module load imasenv/3.24.0/intel
    • module load imasenv/3.24.0/intel/17.0
    • module load imasenv/3.24.0/intel/17.0/1.0.2 

    under assumptions:

    • 3.24.0  is a default DD version
    • intel  is default compiler
    • 17.0 is default compiler version
    • 1.0.2  is default set of libraries compiled by intel
    etc, etc

    "WPCD products"

    ETS workflow is the most complex product being developed by WPCD, however WPCD activity is not limited to ETS development, so this document will refer to "WPCD products" keeping in mind that in most cases it is synonym of "ERTS workflow"

    ...

    • A candidate for a next tagged version
    • Introduced to make sure that update/change requested by developer(s) is "safe"  and will not brake environment (used by large group of developers)
    • Used by a limited group of testers (usually by person who request change plus one/two other testers)
    • Used for limited amount of time (omne, two days)
    • If tests are passed, changes are introduced to RC:
      • patches automatically
      • library updates (that may change APIs) after confirmation coming from WPCD
    • NBBTW: Alpha version is an equivalent of "module load imasenv/x.y.z/rc; module switch tested-lib/tested-ver" 

    ...