Current solution

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.

...

We need to check that running Kepler in such mode is possible, it involves a few actions, mainly on Michal, but with help of others when/where needed:

Preparation for the test

To simulate the case where we run everything from the central installation I am working on a local copy with all the access rights set to read only

> chmod a-w kepler

System variables used by Kepler

At the moment, the way Kepler is executed, can be controlled by the set of environment variables and Java properties

_JAVA_OPTIONS                  - this is the heaviest way of altering Java and Kepler. This option makes it possible to alter
                                 default settings of JVM. It overrides everything else.

KEPLER_JAVA_OPTIONS            - equivalent of _JAVA_OPTION however, this variable alters only Kepler
                                 example: setenv KEPLER_JAVA_OPTIONS "-Xss20m -Xms1g -Xmx4g -Dsun.java2d.xrender=false"
                               
KEPLER_DOT                     - points to root director where .kepler and KeplerData directories will be created

PTOLEMYII_DOT                  - points to root director where .ptolemyII directory will be created

KEPLER_WORK_DIR                - points to location where Kepler will be started. This way, it's possible to change
                                 location of current directory (instead of $KEPLER it will be pointed by $KEPLER_WORK_DIR)
                                 alternatively, this value can be passed via: -Dkepler.work.dir=....
                                 
-Duser.home=                   - This variable is passed to Kepler, this way it's possible to change user.home inside Kepler

-Duser.start.dir=              - This variable allows to pass information regarding current directory. It's possible to access
                                 this variable later on by calling System.getProperty("java.property.name")

Preparation for the test

To simulate the case where we run everything from the central installation I am working on a local copy with all the access rights set to read only

> chmod a-w kepler

Test installation is hereTest installation is here: /gss_efgw_work/work/g2michal/cpt/development/isolated_kepler/kepler 

...

> module load itmenv
> setenv KEPLER /gw/switm/kepler/trunk/R6.0.7/kepler
> module switch scripts/R4

# /gss_efgw_work/work/g2michal/cpt/issues/batch_and_central_kepler/Test.xml
# contains sample workflow that we can use for testing

# $ITMSCRIPTDIR/batch_submission/wrapper-central.sh
# contains modified wrapper script that supports centrally installed Kepler
# it should be backward compatible with regular Kepler

> sbk.sh -name=test_batch_central \
 -file=/gss_efgw_work/work/g2michal/cpt/issues/batch_and_central_kepler/Test.xml \
 -marco:mem=10 \
 -marco:select=1 \
 -marco:cpus=1 \
 -marco:walltime=00:10:00 \
 -marco:block=false \
 -marco:queue=gw \
 -wrapper=$ITMSCRIPTDIR/batch_submission/wrapper-central.sh

Using centrally installed Kepler with sbk via ets module

> module purge
> module load cineca
> module load ets
> module switch scripts/R4.8

> sbk.sh -name=test_2 \
  -file=$ETS_HOME/ETS5.xml \
  -marco:mem=10 \
  -marco:select=1 \
  -marco:cpus=1 \
  -marco:walltime=00:10:00 \
  -marco:block=false \
  -marco:queue=gw

...

We need to check that these scripts (currently copied within Kepler sources when Kepler is being dressed-up) can be stored outside Kepler (public place, versioned, and made available through module) and referenced from the workflow: kplots module will set up a KPLOTS_HOME which points to dir containing all the scripts, we need to check that reading this variable from the workflow will work correctly (getenv). Action on Olivier to create public install of kplots with modules, and on Dmitriy to update ETS workflow to link to Kplots scripts using the env variable set by module. These actions do no depend on Kepler actions above-up) can be stored outside Kepler (public place, versioned, and made available through module) and referenced from the workflow: kplots module will set up a KPLOTS_HOME which points to dir containing all the scripts, we need to check that reading this variable from the workflow will work correctly (getenv). Action on Olivier to create public install of kplots with modules, and on Dmitriy to update ETS workflow to link to Kplots scripts using the env variable set by module. These actions do no depend on Kepler actions above.