The file-based wrapping method

From the Scilab point of view, the computation done in
"code.sce" has the following
steps :

Execute the "input.sce" script which defines the variables
R and F.

Compute the output G = R - F / (100.0 * %pi)

Write the value of the output G into the file "output.txt".

From the OpenTURNS point of view, the computation has the following
steps :

Write the "input.sce" script.

Run the Scilab script code.sce.

Read the value of the output G from the file "output.txt".

The accuracy of the communication

An important detail is that Scilab and OpenTURNS use doubles
for their floating point numbers.
This corresponds to binary 64 floating point numbers in the
IEEE 754 standard, which implies that the number of significant
bits is 53, which corresponds to roughly 16 significant decimal
digits.
In order to have a write-read cycle which is error free, the
theory states that 17 decimal significant digits must be written in the
data file.
This can be achieved with the format "%.17e" in Scilab or Python.

The values printed in the Scilab console
have more significant digits that the values printed
in the file.
This is because the values printed in the console are
to be read by a human (me), while the values printed
in the file are to be read by OpenTURNS.

The Scilab script ends with the statement :

quit;

This makes Scilab exit and prevents from entering in the
classical interactive mode that we use most of the time.
Here, we are interested only in the Scilab engine and
this is why we use the "batch" mode.

Executing Scilab from Python

In order to run Scilab from Python, we
could directly use the os.system function, as
in the following example:

os.system("Scilex -nwni -f code.sce")

One problem with this method is that, on the MS Windows platform,
if we launch a subprocess from within a non-console process,
then a console window temporarily appears.
This is especially ugly in the context of a Monte-Carlo simulation,
since hundreds of these windows appear.

In order to solve this problem, we can use the
subprocess Python module and, more precisely, its
subprocess.Popen function.

The remaining issue is that subprocess does not use the
PATH environment variable.
Hence, we have to give the absolute path to the Scilex
executable, even if this path is available in the PATH
environment variable.
This is why we defined the resolve_path as in the page:

This script is made of two separate parts.
In the first part, we define a classical Python
function, called myScilabFunction, and execute it.
In the second part, we define an OpenTURNSPythonFunction
and make it call the previously defined myScilabFunction
function.

There are several ways to proceed, but I personnally
use the following method.

We could try to reduce the extra startup time required to load the Scilab engine. Indeed, the method we have presented is not that fast, partly because it basically runs the Scilab executable everytime. The call_scilab module for Scilab (by S. Ledru) enables to call Scilab from a C/C++ library:

Creating an OpenTURNS wrapper based on call_scilab would require a bit more work and compilation, but should surely make the computations much faster, in the sense that it will make Scilab behave as a classical C library, without extra startup time. The lack of example with this method has been reported in Ticket #508.