...

• 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, etc - not important concerning discussed scenario

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

Separation of actors 

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...

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
• 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?  

Implementation