It looks like (from user's perspective) we miss simplified way of choosing "dressed" Kepler and workflow that will be used to launch ETS. 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. versionR5.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 ETS
# 1. log in to machine # 2. initialise environment > module load ets_workflow # 3. run the autoGui > launch_kepler.sh
autoGui
is started, user can use his version of ETS
with the default workflow loaded by environment.
1.2. Use-case 2 - running existing installation of ETS after new version was released - using already installed version
In this scenario, system was upgraded and new release of tools was installed
- release of new
Kepler
(e.g. versionR5.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 ets_workflow # 3. run the autoGui > launch_kepler.sh There is a new release of Kepler. Do you want to upgrade [Y/N]?: 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 ETS after new version was released - using upgraded release
In this scenario, system was upgraded and new release of tools was installed
- release of new
Kepler
(e.g. versionR5.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]?: Y
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.