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

Compare with Current View Page History

« Previous Version 16 Next »

1. State of the Art

Current layout of components generated by FC2K is based on Kepler's module layout. The reason for such layout is based on historical choices - related to Kepler being a main workflow engine. Python based actors (being an extension to already existing solution) exploit the same layout. It means, parts of the Python code depend strongly on components created by FC2K.

1.1. Generated code

FC2K generates:

  • Kepler actor
  • Python actor
  • Resources used by both: Python and Kepler actors 
    • libActor.so
      • embeds user code
      • provides Fortran/C wrapper that reads/write IDSes
      • stored in $KEPLER/imas/lib64
    • Actor.exe
      • executable that is used to run actor in standalone mode
        • debugging
        • any kind of batch jobs (e.g. MPI)
    • Other: actor XML parameters, etc. (in case of Python actors these files must be located close to Python module)

1.2. Why Python actor uses $KEPLER ?

  • Python script loads libActor.so  to run user's (Fortran or CPP) code
  • libActor.so is stored in $KEPLER/imas/lib64 directory
    • lib64  is Kepler's default place to look for libraries to be loaded
    • adding library path to LD_LIBRARY_PATH  could be an alternative BUT in case of complex workflows (100+ actors) it can be extremely long  - potential risk of exceeding system limits
  • Python module loads code parameters based on $KEPLER variable

2. Separation of actors 

2.1. Raw idea

Separation of actors, at least in theory, should be easy. It would be enough:

  • To move actor resources out of the $KEPLER
  • To make resources "visible" by both : Kepler and Python actors

but we have also consider many other aspects...

2.2. Open points

Problems to be solved:

  • How to assure compatibility with current version of IMAS?
    • Binaries are build for particular IMAS version 
    • If user switch IMAS version, version of resources should be also changed
  • How to assure compatibility of Kepler or Python workflow with given set of actors
    • Actor A could have different ports (API) in workflow version X and Y
      • This is currently achieved by actor release procedure and maintenance of ETS workflow (release of ETS workflow)
      • ETS workflow + visualisation scripts + Kepler release + actor release + autoGUI release make a package that works.
  • How to make libraries "discoverable" by both actors?
    • LD_LIBRARY_PATH ? 
    • absolute path to libActor.so  ?
    • Any other mechanism?
  • How to design layout of directories to address before-mentioned points?  

3. Proposed solutions

3.1. Independent Python/Kepler actor installations

In this scenario I assume complete separation of Kepler and Python. FC2K should allow choosing whether we want to generate actor for given workflow platform: Python, Kepler, something else in the future. Once platform is selected, FC2K generates source code and "Weighted Companion Cube" - one that contains all the native codes, libraries, etc. - for given platform.

3.1.1. Kepler

TODO: we have to decide whether we want to update the way of generation for Kepler or not

3.1.2. Python

I suggest moving towards Python packages that are self contained packages consisting of:

  • python wrapper
  • shared libraries
  • standalone binary (MPI based execution)
  • default parameters

Each package should be installed inside user's virtual environment - this way, it will be possible to provide users with any version of actor and Python workflow will be composed of loosely coupled actors.

Sample structure of the actor can be found here: /gss_efgw_work/work/g2michal/cpt/development/python_modules/simple 

Inside, we have a sample structure of Python module with native code: demo.c.

src/
|-- actor_demo
|   |-- __init__.py
|   `-- sample.py
|-- demo.c
`-- setup.py

In this scenario, actor is treated as package. It means, we can install it using pip command. This approach provides huge flexibility when it comes to distributing actors. It's very easy to create virtual environment and install actor inside it.

> virtualenv --no-site-packages -p /usr/bin/python2.7 sample
> source sample/bin/activate.csh
> pip install --upgrade --force-reinstall ./src/
> python test.py
Hello from fun
Hello World!

This way, it's possible to create custom work environments where various actors can be installed, reinstalled, where we can mix different versions of actors.

3.2. One common installation of actor resources

3.2.1. Idea

  • To keep all (common) actor resources for both: Python and Kepler actors in one place (directory)
  • To allow switching between "workspaces" (user defined sets of actors)
  • To load actor libraries only for current version of IMAS (if actor is IMAS dependent)

3.2.2. Layout of actor directory

TBD (the same as previously?)

3.2.3. IMAS Workspace


workspaces/
|-- workspaceX
|-- workspaceY
`-- workspaceZ
    |-- common
    |   |-- actor1
    |   |   `-- lib
    |   |       `-- libActor1.so
    |   |-- actor2
    |   |   `-- lib
    |   |       `-- libActor2.so
    |   `-- lib
    |       |-- libActor1.so -> ../actor1/lib/libActor1.so
    |       `-- libActor2.so -> ../actor2/lib/libActor2.so
    `-- imas
        |-- 3.23.2
        |   |-- actorA
        |   |   `-- lib
        |   |       `-- libActorA.so
        |   |-- actorB
        |   |   `-- lib
        |   |       `-- libActorB.so
        |   |-- actorC
        |   |   `-- lib
        |   |       `-- libActorC.so
        |   `-- lib
        |       |-- libActorA.so -> ../actorA/lib/libActorA.so
        |       |-- libActorB.so -> ../actorB/lib/libActorB.so
        |       `-- libActorC.so -> ../actorC/lib/libActorC.so
        `-- 3.24.0
            |-- actorA
            |   `-- lib
            |       `-- libActorA.so
            |-- actorB
            |   `-- lib
            |       `-- libActorB.so
            |-- actorD
            |   `-- lib
            |       `-- libActorD.so
            `-- lib
                |-- libActorA.so -> ../actorA/lib/libActorA.so
                |-- libActorB.so -> ../actorB/lib/libActorB.so
                `-- libActorD.so -> ../actorD/lib/libActorD.so


Workspace layout:

  • directory common - keeps all actors with no IMAS dependencies
  • directory imas/$IMAS_VERSION - keeps all actors build for given version of IMAS
  • directories common/lib and imas/$IMAS_VERSION/lib - keeps links to libraries (to simplify LD_LIBRARY_PATH )


Actor generation:

  • Generated code (wrapper) will be saved under $ACTIVE_WORKSPACE/imas/$IMAS_VERSION/<actor_name> 


Switching workspace

  • LD_LIBRARY_PATH = $ACTIVE_WORKSPACE/common/lib + $ACTIVE_WORKSPACE/imas/$IMAS_VERSION/lib
  • java.lib.path = $LD_LIBRARY_PATH
  • Kepler: rm target/* ? ant compile?


Scripts:

  • list workspaces
  • switch workspace
  • remove workspace
  • create workspace


3.2.4. Open points

  • Do we need directory "common"? Should we care about "no-IMAS" actors (usually there are none of them)...
  • At which level Kepler actor should be separated from their "resources" (i.e. what can be put within workspace)

    • The whole imas related directory ( $KEPLER/imas  )  ?

    • How to achieve this? Kepler module or just CLASSPATH?
  • Could we separate Kepler Core Actors to be independent module?







  • No labels