...
Separate module for FC2K generated actors
Already existing solution based on KeplerData directory
At the moment, Kepler installation consist of few elements
- Base Kepler installation
- Patches applied by us
- Actors that can access ITM/IMAS database (ual actors)
- Actors generated by FC2K
| Code Block |
|---|
itm/src/ ??? cppeu |-- euforia | `-- visit `-- itm |-- cpocontent // nativeall ual codebased -actors could be moveda outsidepart itmof module ? ??? itm ?Kepler release |-- cpodiscard ??? nocpo ? ?// this release ??? bin ? ? ??? build ?would be shared by all the users ? ??? lib ?|-- cpoflush ? ? ??? def ?|-- cpooccurrence ? ? ??? opt ?|-- cpotime ? ??? lib_ext ?|-- itmmatlab |-- nocpo ? ? ??? def ? // ?these two actors ?can be moved ??? opt ? ? ??? src ?to separate module ???|-- nocpoparam ? // ??? bin ? these two actors can be moved to separate module ??? build ?|-- python ??? lib ?|-- recordget ? ??? def ?|-- recordoperation ? ??? opt ?|-- recordset ??? lib_ext ?|-- setbreakpoint ? ??? def ?|-- syncsetvariable ? ??? opt ?|-- tools | ??? src ??? eu ? ??? euforia ? ? ??? visit ? ??? itm // Java code - partially autogenerated, partially taken from ualactors repository ? ??? cpocontent ? ??? cpodiscard ? ??? cpoflush ? ??? cpooccurrence ? ??? cpotime ? ??? itmmatlab ? ??? nocpo // this actor ? ??? nocpoparam // and this actor could have been moved to a different place (new module) ? ??? python ? ??? recordget ? ??? recordoperation ? ??? recordset ? ??? setbreakpoint ? ??? syncsetvariable ? ??? tools ? ? ??? attributes ? ??? ualclose ? ??? ualcollector ? ??? ualdemux ? ??? ualinit ? ??? ualmux ? ??? ualmuxparam ? ??? ualpythonjni ? ??? ualpythonws ? ??? ualslicecollector ??? org ??? kepler ??? module ??? itm |
We can think about new approach, where Kepler base system (plus ual actors) and FC2K based actors are completely separated. This way, we would be able to have centrally installed Kepler and different sets of user based actors. There are two solutions for this
- already existing approach where user based modules are stored inside $HOME/KeplerData directory
- solution based on modifications inside Kepler's core classes - we have to develop new feature that will allow Kepler to find modules in virtually any location
`-- attributes
|-- ualclose
|-- ualcollector
|-- ualdemux
|-- ualinit
|-- ualmux
|-- ualmuxparam
|-- ualpythonjni
|-- ualpythonws
`-- ualslicecollector |
We can think about new approach, where Kepler base system (plus ual actors) and FC2K based actors are completely separated. This way, we would be able to have centrally installed Kepler and different sets of user based actors. There are two solutions for this
- already existing approach where user based modules are stored inside $HOME/KeplerData directory
- solution based on modifications inside Kepler's core classes - we have to develop new feature that will allow Kepler to find modules in virtually any location
New solution based on custom module location
In this case, we have to do some research related to following classes
| Code Block | ||
|---|---|---|
| ||
build/runner/Kepler.java
build/project/ProjectLocator.java
build/UpdatePresentTxt.java |
At the moment, Kepler looks for additional modules only inside ~/KeplerData/kepler.modules (and only in case there is a file "use.keplerdata" inside build-area). I would like to change Kepler such way it can take modules from arbitrary locations.
Modules for actors release procedure
Once we have actors in separate location we can think about modules for actors. In that case, users would be able to do something like this
| Code Block |
|---|
# load module for one release of actors
# and run workflow
> module load actors/ETS_4.10b.10_v5.1.0
> kepler.sh -workflow ETS_for_v5.1.0 -runwf
# switch to another release of actors and run
# workflow again - workflow must be compatible with the set of actors
> module load actors/ETS_4.10b.10_v5.1.1
> kepler.sh -workflow ETS_for_v5.1.1 -runwf |
Handling locked DB file
We have to fix the issue here
| Code Block |
|---|
core/src/org/kepler/util/sql/HSQL.java
The exception below originates in line 731 where the code calls DriverManager to open the connection to the db.
We can try adding a new check for the database being locked and then use System.exit() to stop Kepler nicely instead of throwing exception. |
Create smaller Kepler release
At the moment we provide Kepler release with all the sources, class files, etc. This way, we require:
- lots of space (4 times more comparing to version without sources)
- lots of files to be copied/accessed (6 times more files - 60000 files when shipped with sources vs. 10000 files if we decide to ship stripped version)
We have to add one more step to Kepler build procedure - creating installer. This way, size of Kepler should be reduced. We can think about two, different releases: debug/release.
Release new version of Kepler with fixes
- XML as default save format
- Disabled Provenance and Workflow Manager
- All actors generated by new version of FC2K (with support for Code Parameters)