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

Compare with Current View Page History

« Previous Version 10 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. Implementation - TBD

3.1. Layout of folders - TBD

3.2. Library loading - TBD










  • No labels