3rd Party API Design: Prototyping API ideas

[mducle]

Blocked by #33 Blocking #35

Ideas selected by the working group discussing #33 will be prototyped here.

[mducle]

The discussion document (issue #34) and meeting to agree possible approaches for prototyping never happened. However the required prototyping was completed regardless. Minimum working examples are in this repository. It was determined that:

• A Python interface to Matlab Horace code can be implemented using the Matlab Compiler SDK toolbox.
• Data exchange between the host Python and compiled Matlab module can happen without excessive copying (the raw data array may be wrapped and passed directly).
• The compiled Matlab module may call Python functions (run on the host interpreter) from within a mex file with Python C API bindings. (That is Python-calling-Matlab-calling-Python is possible).
• A standalone Matlab (e.g. with a license) may call a Python subprocess but this Python subprocess is not allowed to functions defined by the parent Matlab directly. (That is Matlab-calling-Python-calling-Matlab is not allowed by the API). It may be possible using a custom C API python module with mex bindings.

These findings means that there should be two discussion documents produced:

1. The Matlab-Python interface (issue #78). This should discuss both how to call Matlab code from within Python (without a Matlab license) and how to call Python code from Matlab (for euphonic and brille), and data exchange between them.

2. User defined model functions in multiple languages (matlab, python, c, c++ and fortran for definite). The required function signatures, consistent with the optimisation framework design, should be detailed. This is the re-branded issue #35