...

For user conveniency it provides two kinds of interfaces: user friendly graphical interface that allows non-experienced users to define an actor in intuitive way and command line interface foreseen for more advanced users that may want to e.g. automatise actor generation process using scripts.

• iWrap generates a Fortran/CPP wrapper, which intermediates between Kepler actor and user code in terms of:
  • reading/writing of in/out physical data (IDS)
  • passing other arguments to/from the actor
• iWrap creates a Python script (aka an actor) that:
  • calls a user code
  • provides error handling
  • calls debugger (if run in "debug" mode)

...

A signature of user code must follow strict rules to allow interaction between it and wrapping actor.  Please use following  >>link<< to get detailed guidelines for integration of native code into workflows using iWrap  

...

Code and actor description

iWrap, to properly wrap the code, needs detailed informations about both: the wrapped code and an actor to be generated. A formal description ot the code provides information about the programming language used, arguments passed to/from the code, type of these arguments, etc, etc, while an actor description tells iWrap how to name generated actor, where to put it, etc. Such descriptions has to be provided in YAML format file, prepared manually, or automatically with help of iWrap GUI.

...

The YAML file consists of two independent parts (aka 'YAML documents'), marked by tags corresponding to their roles: actor_description and code_description . Only code description part is mandatory, while 

...

and  actor description could be provided in a file, or using iWrap commandline switches or interacting with GUI.

The structure of the file is following:

# actor description part - optional 
--- !actor_description
	<see chapter below for details>
...

# code description part - mandatory
 --- !code_description  
 	<see chapter below for details> 
...
 

Native code description

Description of the native code has to be provided as a YAML document. It consist of two parts. The first one contains generic information common for all languages, The latter one contains information specific for a given language of the native code (currently defined only for Fortran and CPP). 

Common part

 Generic information common for all (or at least majority of) programming languages.

• programming_language
  • meaning:  language of physics code
  • value: one of predefined values: 'Fortran', 'CPP'
  • example: 'Fortran'
• code_name
  • meaning:
    • name of user method / subroutine to be called,
    • must be exactly the same as name of called method / subroutine
    • it is used also as an actor name
  • value: string
  • example: 'my_subroutine' 
• data_type
  • meaning: data type handled by the physics code
  • value: one of predefined values: 'Legacy IDS' 'HDC IDS'
  • example: 'Legacy IDS'
• arguments - list of arguments
  • argument definition: 
    • name:
      • meaning: user defined argument name
      • value: string
      • example: equilibrium00   
    • type:
      • meaning: a type of an IDS argument
      • value: 
        • for data type 'IDS': predefined name of one of the IDSes
        • for data type 'HDC' : TBD
      • example: 'equilibrium' 
    • intent
      • meaning: determines if given argument is input or output one
      • value: predefined - string "IN", "OUT"
• code_path: 
  • meaning: path to system library (C, CPP) , script (Python), etc containing the physics code, including method/subroutine to be run
  • value: string, valid path to file
  • example: 'any text'  
• code_parameters:
  • parameters:
    • meaning: path to XML file containing user defined parameters of the physics code
    • value: string, valid path to file
    • example: './code_parameters/parameters.xml'
  • schema:
    • meaning: path to XSD file contains schema of XML parameters, to be able to validate them
    • value: string, valid path to file
    • example: './code_parameters/parameters.xsd'

• documentation:
  • meaning: human readable description of native code
  • value: string
  • example: 'any text'

Language specific part - Fortran/C++

• compiler:
  • meaning: the name/vendor of the compiler (and not compiler command!) used to compile native codes
  • value: string, one of vendors of compilers, currently: 'Intel' or 'GCC'
  • example: 'Intel'
• mpi_flavour:
  • meaning: MPI compiler flavour to be used
  • values: string, one of:  MPICH, MPICH2, MVAPICH2, OpenMPI, etc.
  • example 'MPICH2'
• open_mp:
  • meaning: if user code should be compiled with OpenMP flag
  • values: boolean
  • example 'true'
• system_libraries:
  • meaning: a list of system libraries, managed using pkg-config mechanism,  that has to be used while native code linking
  • value: a list of system libraries names, as they are published by pkg-config 

  • example: 

    - fftw3f - glib - mkl

    
    

• custom_libraries:
  • meaning: additional libraries, not managed by pkg-config mechanism, necessary to link of the physics code :
  • value:  a list of paths to libraries 

  • example: 

    - ./lib/custom/libcustom1.a - ./lib/custom/libcustom2.a

    
    

Example - Fortran code description

--- !code_description
programming_language: Fortran
code_name: demo_code
data_type: legacy
arguments:
-   name: equilibrium00
    type: equilibrium
    intent: IN
-   name: equilibrium01
    type: equilibrium
    intent: IN
-   name: equilibrium10
    type: equilibrium
    intent: OUT
-   name: equilibrium11
    type: equilibrium
    intent: OUT
code_path: ./lib/libmy_lib.a
code_parameters:
    parameters: ./code_paramneters/parameters.xml
    schema: ./code_paramneters/parameters.xsd
documentation: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
    eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
    veniam... '
language_specific:
    compiler: Intel
    mpi_flavour: MPICH2
    open_mp: false
    system_libraries:
    - fftw3f
    - glib
    - mkl
    custom_libraries:
    - ./lib/custom/libcustom1.a
    - ./lib/custom/libcustom2.a

 iWrap graphical interface

>>here<<

wrapping (job description, iWrap)

...