[WIP] MATLAB interface

[stefphd]

Hi Charlie,

I've just written a first draft of the MATLAB interface. It has also some minor changes in the C/C++ interface. For now it's only a draft, may be unstable at the moment.

Track list:

• Create low-level matlab mex functions result = uno_optimize(model[, options, callbacks]) and options = uno_options([preset])
• Create readme for matlab interface
• Create HS015 problem example
• Use explicit sparsity pattern in matlab low-level interface
• Add argument validation functions in interfaces\Matlab\Uno_mex_utilities.hpp
• Add argument validation inuno_optimize mex function
• Add high-level (fmicon-like) interface
• Add github action (Windows)
• Add github action (MacOS)

[cvanaret]

Really cool Stefano!
Do we need a self-hosted runner with a Matlab license to test the interface in a Github Action or can we do that on the Github runners?

[stefphd]

Hi @cvanaret

As far I know, it's possible to use Matlab on the Github runners for public repos, so no need for self-hosted runners (see here). So far, I was able to build a Matlab mex (via cmake) even for a private repo without a Matlab license, as this step only requires the Matlab installation and doesn’t actually call MATLAB itself. I’ll try running a test on GitHub runners to confirm that this works as well.

[stefphd]

Matlab interface is almost completed; a few tests may still be required.

Currently:

• The high-level interface should be quite robust and stable (it mimics the Matlab fmincon command, with a few differences explained in the README)
• The low-level interface is more risky (an incorrect problem setup may cause Matlab to crash with a segmentation fault, etc.), although it provides complete control over Uno. Under the hood, the high-level interface employs the low-level interface.

I was able to successfully run the MATLAB test examples on both Windows and macOS GitHub runners; however, some Python tests are still failing (I don’t know the reason yet).

Note that macOS was quite challenging: a segfault during cleanup on exit causes MATLAB to crash. The current workaround is to lock the compiled MEX file to prevent it from being unloaded, so that TLS cleanup handlers remain valid (cf. matlab_openmp_tls_bug).

[cvanaret]

Great job! I'll have a look why the Python workflows fails.

[cvanaret]

OK it seems to work. The bug had nothing to do with the Matlab interface but was apparently caused by the class UserStreamCallback being moved to the unopy files (for which LTO was enabled).
I'll do a separate fix which you can then merge.

[stefphd]

Thanks Charlie!!!
I created a base class UserStreamCallback for a common interface to all stream callbacks (CStreamCallback and MatlabStreamCallback) to avoid duplicated code.

Edit: I see that the Python interface uses a slightly different approach. I'm still not sure which one is best.

[cvanaret]

It's ok if the Python and Matlab interfaces don't use exactly the same approach. We should "ship fast" and improve later :)