Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

 Actor execution and debug modes


Image Added

Kepler actor, could be run in two main execution modes: JNI and 'standalone' and related debugger modes.

 Execution modes 

 JNI mode

User codes are run directly from an actor, within a Kepler process, using Java JNI mechanism.

 Standalone mode

When 'standalone' mode is set, Kepler runs an actor, as an independent system process, waiting only for its finish and produced outcomes.

'Standalone' mode uses more system resources (it is a separate system process!), however running actor in this mode may solve memory issues related with: insufficient memory owned by JVM or memory overriding (user code is run in separate memory space). 

More in details - when actor with is fired in 'standalone' mode:

  • All actors files (user library, wrapper, standalone.exe) are copied to ~/public/KEPLEREXECUTION/<actor_dir> folder
  • An input.txt file is created (it contains all actor inputs, like CPO/IDS meta descriptions, strings, primitives values, XML params strings, etc)
  • A standalone C/Fortran executable  (<actor_name>.exe) is run. It:
    • reads input data from input.txt
    • calls actor wrapper (defined in FortranWrapper.f90)


Please notice that 'standalone' mode  is different from JNI execution:

  • Actor is run separately (e.g. no preceding actors in w-f can affect its execution)
  • User code is run from C/Fortran binary (in real case, in w-f, it is run by JNI)
  • It is run with different memory settings as in real w-f execution

 Debugging a user code

Sequential codes

A user codes could be debugged using a chosen debugger in a way corresponding to execution modes described above. 

  1. JNI/Attach - Debugger attaches to a running Kepler process:
    • User could debug what REALLY happens in w-f, including JNI calls, influence of previous actors, etc, etc...

    • Proces cannot be restarted. Stopping or killing the proces being debugged kills JVM. 
  2. Standalone - debugger 'owning' executable  (<actor_name>.exe)  is started with as a separate process
    • The code being debugged is run in somehow 'artificial' environment that differs from (usually used) JNI mode of an actor 
    • No preceding actors in w-f can affect its execution so error related with memory issues usually cannot be reproduce

MPI codes

Debugging MPI codes is available only from commandline. User should go to an actor folder (~/public/KEPLEREXECUTION/<actor_dir>), and run  'mpiexec' providing appropriate debug options

An example:

Code Block
mpiexec <debugger switch>  -np 2 ./<actor_name>_exe 


Unfortunately not only switches values differ regarding to MPI implementation, but also 'intel's' and 'gnu's' mpiexec behaves differently: under intel one it is impossible to restart an application that already finished...


MPI VendorTotalView GDB
Intel-tv-gdb
GNU

-tv (deprected}

-- debug --debugger totalview


-- debug --debugger gdb



Actor cache

Info
iconfalse
titleInitial request

To add  a little complexity to the FC2K generated wrappers would be to add an optional new port (triggered by a choice in the GUI) which would take as input 0 or 1.

  • In the case of a 1, the physics code would be called in the usual way, but the result would also be "remembered" internally by the wrapper.
  • In the case of a 0, the physics code would not be called, but the result remembered by the wrapper would be replayed.

This would allow for cleaner, less complicated workflows and a great deal more flexibility in changing the frequency with which codes are called.

...