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

Compare with Current View Page History

Version 1 Next »

It looks like (from user's perspective) we miss simplified way of choosing Kepler and workflow that will be used. In fact, the same sort of issues will affect Python based workflows.

At the moment, release of Kepler follows (heavy simplified process):

  • release of new FC2K (e.g.: version R4.2.6 this will be transparent for users - they don't need FC2K for day to day usage)
  • release of new Kepler  (e.g. version R5.0.16_v5.2.2)
  • release of all actors (based on tag, e.g.: v5.2.2)
  • release of supplementary components (e.g.: kplots)
  • release of workflow (e.g.: ETS_v5.2.2.xml)
  • release of autoGui (e.g.: 1.1)

all these components make user based environment.

In order to use it, user will.

1.1. Use-case 1 - running existing installation of Kepler and workflow

# 1. log in to machine
# 2. initialise environment

> module load itmenv
> module load ets_workflow

# 3. run the autoGui

> launch_kepler.sh

autoGui is started, user can use his version of Kepler with the default workflow loaded by environment.

1.2. Use-case 2 - running existing installation of Kepler and workflow after new installation was released

In this scenario, system was upgraded and new release of tools was installed

  • release of new Kepler  (e.g. version R5.0.16_v5.2.3)
  • release of all actors (based on tag, e.g.: v5.2.3)
  • release of supplementary components (e.g.: kplots)
  • release of workflow (e.g.: ETS_v5.2.3.xml)

With current layout of Kepler and actors, we are forced to create new version of Kepler.


# 1. log in to machine
# 2. initialise environment

> module load itmenv
> module load ets_workflow

# 3. run the autoGui

> launch_kepler.sh
There is a new release of Kepler. Do you want to upgrade [Y/N]?:

User presses N and currently installed version of autoGui and current version of Kepler are used. No changes inside user's settings are done.

1.3. Use-case 3 - running existing installation of Kepler and workflow after new installation was released

In this scenario, system was upgraded and new release of tools was installed

  • release of new Kepler  (e.g. version R5.0.16_v5.2.3)
  • release of all actors (based on tag, e.g.: v5.2.3)
  • release of supplementary components (e.g.: kplots)
  • release of workflow (e.g.: ETS_v5.2.3.xml)

With current layout of Kepler and actors, we are forced to create new version of Kepler.

# 1. log in to machine
# 2. initialise environment

> module load itmenv
> module load ets_workflow

# 3. run the autoGui

> launch_kepler.sh
There is a new release of Kepler. Do you want to upgrade [Y/N]?:

User presses Y. Script performs upgrade of all tools installed for the user and starts most recent version of autoGui and most recent version of Kepler. Previous version of user's installation are preserved and it will be possible to go back to this version later.

1.4. Use-case 4 - running previous installation of Kepler

In this scenario, user decides it's required to run previous simulation with old set of actors. User runs dedicated script

> list_keplers.sh
[ ] R5.0.16_v5.2.2
[ ] R5.0.16_v5.2.3
[X] R5.0.17_v5.2.3

> select_kepler.sh R5.0.16_v5.2.3
> list_keplers.sh
[ ] R5.0.16_v5.2.2
[X] R5.0.16_v5.2.3
[ ] R5.0.17_v5.2.3

> launch_kepler.sh --nocheck

In this scenario, user decides to use previously installed Kepler and skips checking for newer version. Selected version of Kepler is started.

  • No labels