1. State of the Art
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)
- executable that is used to run actor in standalone mode
- Other: actor XML parameters etc, etc - not important concerning discussed scenario
- libActor.so
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
directorylib64
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
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
- 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
3.1. Layout of folders
Library discovery mechanism