MATLAB Interface Is Incompatible with the Latest Version of MATLAB

[ssun30]

Problem description

The latest version of MATLAB (R2024b) comes with Intel MKL as the default library for BLAS and LAPACK. This version of MKL is built with ILP64 where a 64-bit int type is used for all integers in order to support very large array sizes (>2^31-1). The default OpenBLAS package that comes with Cantera uses LP64 where standard integers are 32-bit and the long type is required for 64-bit integers. This causes an incompatibility issue when data in an array is passed back and forth between MATLAB and OpenBLAS. In some cases this will just return an incorrect type error but in the worst case scenario will cause a buffer overflow and instantly crashes MATLAB.

A partial workaround exists to resolve this problem, as mentioned in this thread. We can bypass ILP64 MKL by setting the environment variable LD_PRELOAD and force MATLAB to use the LP64 OpenBLAS library in the Cantera environment. This will correctly set the types of integers and Cantera will successfully solve any linear algebra problems. However, this workaround is unstable and will cause crashes when the plot function is invoked, for example to plot to concentration of species over time.

Steps to reproduce

1. In MATLAB, run ctLoad;
2. Run example equil.m;
3. Exit MATLAB and set LD_PRELOAD to the location of the OpenBLAS library in your Cantera environment;
4. Repeat 1) and 2).

Behavior

The gas object will fail to equilibrate, this error appears in the MATLAB terminal:

Error using ctFunc (line 11)

*******************************************************************************
CanteraError thrown by MultiPhase::equilibrate_MultiPhaseEquil:
No convergence for T
*******************************************************************************

Error in ThermoPhase/equilibrate (line 493)
            ctFunc('thermo_equilibrate', tp.tpID, xy, solver, rtol, ...
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in equil (line 39)
        gas.equilibrate('HP');
        ^^^^^^^^^^^^^^^^^^^^^

while this error will appear in the linux terminal:

Intel oneMKL ERROR: Parameter 6 was incorrect on entry to DGEMV

Parameter 6 of DGEMV is the leading dimension of a matrix, which in MKL ILP64 is a 64-bit int type but in OpenBLAS is a 64-bit long.

After setting the LD_PRELOAD variable to the correct OpenBLAS location. This example will successfully run until the plot function is invoked to plot the equivalence ratio vs. temperature. MATLAB instantly crashes and throws either a free(): invalid pointer error or munmap_chunk() error, both of which indicate a memory corruption has occured. It is unknown whether other built-in MATLAB functions will cause these crashes, but simple manipulations on the data being plotted did not return any errors or cause crashes. A crash dump info is included below:

matlab_crash_dump_510456-1.txt

System information

• Cantera version: 3.2.0
• OS: Ubuntu 22.04.5 LTS
• Python/MATLAB/other software versions: MATLAB R2024b

Additional context

Older versions of MATLAB are untested.

[ssun30]

I will try to check whether using the ILP64 version of OpenBLAS will solve the incompatibility issue and whether it will be stable.

[speth]

I think the two challenges you will run into here are:

1. The "size of integer to use with LAPACK" is not currently a configurable variable in the Cantera code or build process. Changing this is probably a good idea, but it will be tricky. On top of that though is the choice of what type of LAPACK interface to link to in our Conda packages. We never deal with matrices large enough to need 64 bit integer indices, and it might cause other compatibility problems if we switched.
2. You will also need to have SUNDIALS built with a configuration to use a 64-bit integer LAPACK library. I don't know if there are conda-forge packages for that.

[ssun30]

I think the two challenges you will run into here are:

1. The "size of integer to use with LAPACK" is not currently a configurable variable in the Cantera code or build process. Changing this is probably a good idea, but it will be tricky. On top of that though is the choice of what type of LAPACK interface to link to in our Conda packages. We never deal with matrices large enough to need 64 bit integer indices, and it might cause other compatibility problems if we switched.

2. You will also need to have SUNDIALS built with a configuration to use a 64-bit integer LAPACK library. I don't know if there are conda-forge packages for that.

I think for the time being the best course of action is bypassing MATLAB's built-in MKL. I don't think 64-bit integer adoption rate is picking up anytime soon so most people will be working with LP64. The LD_PRELOAD trick will work but it's especially strange that invoking plot in MATLAB causes a memory overflow and I still need more testing to see what else in MATLAB triggers it. We now have dedicated technical support from Mathworks so hopefully they can give some insight into this issue. In addition, all my testing so far has been done on Linux x86_64 and the behavior on Mac and Windows is unknown.

[ischoegl]

Fwiw, in the 'new' CLib I am currently working on, we'll have the option to generate code for different integer formats. This may involve some 'lossy' type casting between ILP64 and LP64, but that way, we'd have a clean separation of what MATLAB sees at the interface and what Cantera does under the hood. (To explain: the sourcegen converter implements 'crosswalks' between variable types that are directly integrated into the code generation.)