Table of Contents |
---|
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
Code Block |
---|
> 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
Code Block |
---|
_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
Code Block |
---|
> chmod a-w kepler |
Test installation is hereTest installation is here: /gss_efgw_work/work/g2michal/cpt/development/isolated_kepler/kepler
...
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.
Info | ||
---|---|---|
| ||
This work has been carried out within the framework of the EUROfusion Consortium and has received funding from the Euratom research and training programme 2014-2018 under grant agreement No 633053.The scientific work is published for the realization of the international project co-financed by Polish Ministry of Science and Higher Education in 2019 and 2020 from financial resources of the program entitled "PMW"; Agreement No. 5040/H2020/Euratom/2019/2 and 5142/H2020-Euratom/2020/2”. |