1. Use cases:

1.1. Wrapper modes:

• interactive - user code is run directly from wrapper
• batch - user executable is sent to a queue

1.2. Execution modes

User code can be:

• Sequential
• Parallel:
  • MPI
    • MPICH
    • OpenMPI
  • and/or OpenMP

1.3. Debugging modes:

• standalone - debugger launches executable containing user code in a separate process
• attach - debugger attaches to running process executing user code

1.4. Sandbox

2. Wrapper API - current status

def actor_name(integer0, integer1, core_profiles0, exec_type='ctypes', **kwargs):

2.1. User code arguments (IN/OUT)

Argument can be

• IDS
• primitive type
• array of primitive types
• string

2.2. Execution type

• Named argument (exec_type='').
• Current values of exec_type :
  • ctypes - interactive execution (yes - this name is REALLY CONFUSING)
  • mpi_local - run as MPI job
  • dbg - to keep compatibility with obsolete 'debug' argument of wrapper

BP: IMHO it should be removed and defined in other way, as execution modes requires additional set of info

2.3. Additional arguments 

Auxiliary keyword arguments:

dbgmode = kwargs.get('dbgmode', False)
mpi_processes = kwargs.get('mpi_processes', 1);

if kwargs.get('lib_opt',False):

if kwargs.get('get_output_idss', True):

results.append(arg['cval'].value)
if kwargs.get('strip_output', True) and isinstance(results[-1], string_types):

3. Wrapper API - new design

only kwargs !!!!

def actor_name(**kwargs):

All arguments will be stored in data holding objects and wrapper will check what is defined inside kwargs.

Separate objects will hold info about:

• user code arguments - autogenerated
• diagnostic info
• execution modes
• debug

4. Open points

1. Sandbox:
   1. Do we need this feature?
2. Alternative library:
   1. Do we need this feature?