Codecov Report

❌ Patch coverage is 35.11111% with 146 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.43%. Comparing base (96f98af) to head (3f206ac).
⚠️ Report is 11 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1868      +/-   ##
==========================================
- Coverage   75.58%   75.43%   -0.15%     
==========================================
  Files         451      454       +3     
  Lines       56369    56348      -21     
  Branches     9299     9299              
==========================================
- Hits        42607    42508      -99     
- Misses      10619    10698      +79     
+ Partials     3143     3142       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for looking into this, @ssun30. Overall, I believe introducing new 4,000+ line definectMatlab.m and a 22,000+ line ctMatlabData.xml are quite problemantic from a maintenance perspective. Likely, these can be autogenerated (if they haven't been already), and I am 👎 on adopting them in their hard-coded form.

Regarding a new "C++ interface" it does look like a misnomer to me, as things are still routed through Clib, correct? As I have pointed out elsewhere, the experimental CLib version will provide better control over type conversions, and could potentially avoid the additional interface layer this PR is introducing.

That said, I'm not opposed to the solution per se, but the implementation is problematic.

Thanks for looking into this, @ssun30. Overall, I believe introducing new 4,000+ line definectMatlab.m and a 22,000+ line ctMatlabData.xml are quite problemantic from a maintenance perspective. Likely, these can be autogenerated (if they haven't been already), and I am 👎 on adopting them in their hard-coded form.

Regarding a new "C++ interface" it does look like a misnomer to me, as things are still routed through Clib, correct? As I have pointed out elsewhere, the experimental CLib version will provide better control over type conversions, and could potentially avoid the additional interface layer this PR is introducing.

That said, I'm not opposed to the solution per se, but the implementation is problematic.

Yes, the goal is for the library definitions to be auto-generated (in fact they are, mostly). The library definition files are now included just for testing the CI. The main problem so far is some of the auto-generated definitions are missing some <MLTYPE>, <DIRECTION>, and <SIZE> arguments that for now are filled in manually. As a proof of concept I used MATLAB's default clibPublishInterfaceWorkflow which is a generic workflow. But for our own interface I will use a custom version of this workflow to build the interface. I already have a few MATLAB scripts in the works to do the automation but still requires some polishing to truly remove manual modifications.

Apart from better type conversion, this new interface has several other advantages compared to the loadlibrary approach:

• Out-of-process execution: the memory spaces on either side are isolated. The current 'experimental' interface is susceptible to memory leaks and requires fail-safes to clear temporary pointers and call class destructors. This can become a problem if the user lacks knowledge of how to safely manage memory. Running the Cantera library out of process ensures MATLAB would not crash if the library crashes.
• Auto doc gen: this new approach of generating the library definitions automatically generates documentations from the header files, we can then have a script to pull the docstrings from the library definitions into the MATLAB wrapper. I think this works well with the experimental Clib which will be fully documented with sourcegen.
• Long term support (hopefully): MathWorks is (again) no longer maintaining the MATLAB-to-C interface we are using right now and only this new one is actively developed and maintained.

Eventually my vision is for the wrapper layer (at least most parts of it) to also be automatically generated from the library definitions. The manually coded part would be a mapping between the MATLAB methods with their clib counterparts, and maybe some constructors which for now have a lot of manually coded conditionals.

@ssun30 … thank you for the comment but I am not sufficiently familiar with the approach. Overall, the final solution needs to be simple as anything else is unmaintainable. The team of maintainers is extremely small so we need to avoid anything that could become an unreasonable burden.

@ssun30 … thank you for the comment but I am not sufficiently familiar with the approach. Overall, the final solution needs to be simple as anything else is unmaintainable. The team of maintainers is extremely small so we need to avoid anything that could become an unreasonable burden.

@ischoegl I just added the scripts to automatically generate the interface. I don't think it's adding anything to complicate the maintainability. I think it's mostly in a "leave and forget" state where any future changes to the clib should automatically apply to the clib interface.

I will also roll back some unnecessary changes made to the wrapper functions later.

Thank you @ssun30 for removing the unnecessary files (they should also be removed from the git history by squashing commits).

Overall, I have the sneaking suspicion that this additional layer does something similar to what Clib already does: separate memory. CLib wraps all C++ internals and makes them safe to handle in a C-style interface. If the outcome of this PR is that we have two (or more) memory copies in each direction, then it is likely not an efficient solution. To use your terminology: Clib handles memory from C++ (and delivers copies of C++ variables etc. at the Clib API), and the MATLAB wrapper then does the same once more before it is accessible by MATLAB? It seems to be both inefficient and overly complicated.

@ssun30 ... I wanted to follow up once more as there still is a lack of clarity to me. From where I stand, the approach for the MATLAB toolbox prior to this PR was as follows:

1. C++ code base (class based)
2. CLib (to be replaced by auto-generated 'experimental' CLib outside of this effort) wraps classes into C-style functions
3. MATLAB interface; hand-coded; calls into CLib via calllib; mimics classes available in Python interface

If I understand correctly, the direction of this PR would introduce an additional layer:

1. C++ ... see above
2. CLib ... see above
3. Autogenerated MATLAB layer (via ctBuildInterface)
4. Actual MATLAB Cantera toolbox; hand-coded; calls into wrapper via clib.ctMatlab.(funcName); mimics classes available in Python interface.

Please let me know if I understand this correctly.

One other clarification from me, when and by whom is the ctBuildInterface function called?

@ssun30 ... I wanted to follow up once more as there still is a lack of clarity to me. From where I stand, the approach for the MATLAB toolbox prior to this PR was as follows:

1. C++ code base (class based)
2. CLib (to be replaced by auto-generated 'experimental' CLib outside of this effort) wraps classes into C-style functions
3. MATLAB interface; hand-coded; calls into CLib via calllib; mimics classes available in Python interface

If I understand correctly, the direction of this PR would introduce an additional layer:

1. C++ ... see above
2. CLib ... see above
3. Autogenerated MATLAB layer (via ctBuildInterface)
4. Actual MATLAB Cantera toolbox; hand-coded; calls into wrapper via clib.ctMatlab.(funcName); mimics classes available in Python interface.

Please let me know if I understand this correctly.

Hi @ischoegl , yes this is the intention. @bryanwweber The ctBuildInterface function will be used by 1) the CI workflow 2) the SCONs script when user installs the interface (not implemented yet) and 3) the MLTBX's setup script as an alternative way for the user to install the interface.

@ssun30 / @rwest ... I created some documentation for Cantera's automated code generation approach as well as for the new CLib API, which was just merged into the development version. There's also rudimentary documentation for the .NET API, which combines auto-generated code with a hand-coded API. We're already using jinja templates elsewhere, and it would be easy to use for the MATLAB API.

PS: Fwiw, I also added a stub for the MATLAB Toolbox Reference

We had a long and I think helpful meeting at MathWorks last week, and have some thoughts on this. There are pros and cons to the many options. One concern (if I got this correct) is the callib method is not going to see any further fixes from their end. (And currently segfaults?). Whether there's a way to get direct to the Cantera C++ without the C layer (reducing the number of layers) I can't recall and/or lost track. The saga continues....

We had a long and I think helpful meeting at MathWorks last week, and have some thoughts on this. There are pros and cons to the many options. One concern (if I got this correct) is the callib method is not going to see any further fixes from their end. (And currently segfaults?). Whether there's a way to get direct to the Cantera C++ without the C layer (reducing the number of layers) I can't recall and/or lost track. The saga continues....

@rwest ... thanks for chiming in! I wasn't aware that MathWorks was thinking of discontinuing low-level calllib support, but there still are limitations to their C++ support, which, - at least when we discussed this at the very beginning of the toolbox work, - were deemed too limiting (fwiw, we do use vectors of shared pointers to objects in C++, see a CLib wrapped example here). These limitations aren't an issue when calling into Cantera's CLib.

Regarding segfaults: I am not aware of what exact issues you are referring to - if there's an issue in Cantera's CLib, then the right approach would be to file an issue report on GH (there's the caveat that there now are two CLib versions). One thing I need to point out, however, is that the current version of the Cantera MATLAB toolbox mostly ignores exceptions being thrown in the C++ layer. Instead, all the checks are re-implemented, which creates the problematic situation that C++ exceptions are ignored if there's a missing MATLAB guard, and subsequent calls into CLib may cause hard crashes. It would be, imho, preferable to let C++ handle all exceptions and just rethrow them in MATLAB.

Finally, at least to me it appears that the MATLAB code generation envisioned by this PR is perpendicular to the intent of Cantera/enhancements#39. Ideally, class methods that call into CLib should be generated automatically rather than hand-coded. This admittedly goes well beyond what I believe makes sense for the initial release of the new MATLAB toolbox, which is overall close.

I'll let Su try to correct or clarify my comments above. I likely got some things wrong. I agree with this "goes well beyond what I believe makes sense for the initial release of the new MATLAB toolbox, which is overall close."
I think we're still exploring the next new new MATLAB interface 😝 but should get the current one in soon.

I'll let Su try to correct or clarify my comments above. I likely got some things wrong. I agree with this "goes well beyond what I believe makes sense for the initial release of the new MATLAB toolbox, which is overall close." I think we're still exploring the next new new MATLAB interface 😝 but should get the current one in soon.

Sounds good. From my perspective, what’s “under the hood” is secondary as long as things work and the overall approach is consistent with Cantera’s overall design philosophy. If done right, implementation details can be swapped out in the future without a change in the user-facing API.

This interface requires a MATLAB release newer than R2020b.

As an aside, if we require a much newer version than in the past, I’d suggest to go to R2021a, where support for keyword arguments is added.

@ssun30 ... I looked at some of the MATLAB documentation. If this ends up being just for 'out-of-process' execution, I would prefer to make things as simple as possible and skip the publication of an interface, e.g., the 'alternative' approach that calls clib commands directly in the library namespace. In effect, this is already done in this PR. My hangup is that there is no need for the published/generated wrapper file, as you're using direct calls in ctFunc.m anyway?

To make sure that I understand the process: Is is true that, using the modern C++ Interface, it may be as simple as

% Step 1: Generate definition with multiple headers, single library
defFile = clibgen.generateLibraryDefinition( ...
    ["ct_<one>.h", "ct_<two>.h", ..., "ct_<three>.h"], ...
    "Libraries", "cantera_shared.dll", ...
    "LibraryName", "ctMatlab");

% Step 2: Build interface  
build(defFile);

% Step 3: Configure for out-of-process execution
libraryconfig = clibConfiguration("ctMatlab", ExecutionMode="outofprocess");

% Step 4: Call functions from any header - all under single namespace
result = clib.ctMatlab.someFunction(42);

Steps 1 and 2 need to be run once (unless rebuilding), and step 3 does the actual out-of-process configuration during a MATLAB session.

Of course, there needs to be additional code to resolve file locations and shared library types, where there is overlap with the installation question from #1911. I'd suggest resolving that one first, then rebase this one to make it clear what is done exactly.

Hi @ssun30 ... thanks for trying to rebase, but it appears that some of the recently merged work on #1911 was undone and/or changed to an earlier version.

I also noticed that in your commit "[MATLAB] Proof-of-concept for the new Interface" (currently 4c13ec0) you are adding a rather large XML file that is later removed.

@ssun30 ... I looked at some of the MATLAB documentation. If this ends up being just for 'out-of-process' execution, I would prefer to make things as simple as possible and skip the publication of an interface, e.g., the 'alternative' approach that calls clib commands directly in the library namespace. In effect, this is already done in this PR. My hangup is that there is no need for the published/generated wrapper file, as you're using direct calls in ctFunc.m anyway?

To make sure that I understand the process: Is is true that, using the modern C++ Interface, it may be as simple as

% Step 1: Generate definition with multiple headers, single library
defFile = clibgen.generateLibraryDefinition( ...
    ["ct_<one>.h", "ct_<two>.h", ..., "ct_<three>.h"], ...
    "Libraries", "cantera_shared.dll", ...
    "LibraryName", "ctMatlab");

% Step 2: Build interface  
build(defFile);

% Step 3: Configure for out-of-process execution
libraryconfig = clibConfiguration("ctMatlab", ExecutionMode="outofprocess");

% Step 4: Call functions from any header - all under single namespace
result = clib.ctMatlab.someFunction(42);

Steps 1 and 2 need to be run once (unless rebuilding), and step 3 does the actual out-of-process configuration during a MATLAB session.

Of course, there needs to be additional code to resolve file locations and shared library types, where there is overlap with the installation question from #1911. I'd suggest resolving that one first, then rebase this one to make it clear what is done exactly.

Your description is true. The user can call all functions defined in the headers with the modern C++ interface, but the same is also true for the existing calllib approach. The wrapper files exist solely to ease the learning curve so a user can, for example, just call t1 = gas.T and ctFunc calls the correct function for them, instead of t1 = clib.ctMatlab.thermo_temperature(gas.id).

Hi @ssun30 ... thanks for trying to rebase, but it appears that some of the recently merged work on #1911 was undone and/or changed to an earlier version.

I also noticed that in your commit "[MATLAB] Proof-of-concept for the new Interface" (currently 4c13ec0) you are adding a rather large XML file that is later removed.

I will check commits and remove changes that undo the recent changes.

One question I have is that, currently scons install still moves the legacy clib headers to the installed location while the generated clib stays under interfaces/clib/include. I'm planning to open a PR to resolve the installation issues but also switch to the new generated clib. When are we going to deprecate the legacy clib?

Your description is true. The user can call all functions defined in the headers with the modern C++ interface, but the same is also true for the existing calllib approach. The wrapper files exist solely to ease the learning curve so a user can, for example, just call t1 = gas.T and ctFunc calls the correct function for them, instead of t1 = clib.ctMatlab.thermo_temperature(gas.id).

Thanks for confirming. Overall, please understand that I am fully onboard with the wrapper you've been working on for some time (the 'out-of-process' approach changes this only marginally). I simply want to point out that the 'published interface' (i.e., the generated definectMatlab.m file) is an unnecessary step and should be removed; it is a distraction and not useful to the user base. Instead, the C++ interface should be used as a drop-in replacement for the older calllib approach.

One question I have is that, currently scons install still moves the legacy clib headers to the installed location while the generated clib stays under interfaces/clib/include. I'm planning to open a PR to resolve the installation issues but also switch to the new generated clib. When are we going to deprecate the legacy clib?

The legacy CLib is de facto deprecated now. The MATLAB toolbox is the only API left that depends on it, and the plan is to remove the legacy CLib immediately after the 3.2 release. Beyond, I strongly believe that installation and CLib migration should be addressed in separate, single-issue PRs.

Your description is true. The user can call all functions defined in the headers with the modern C++ interface, but the same is also true for the existing calllib approach. The wrapper files exist solely to ease the learning curve so a user can, for example, just call t1 = gas.T and ctFunc calls the correct function for them, instead of t1 = clib.ctMatlab.thermo_temperature(gas.id).

Thanks for confirming. Overall, please understand that I am fully onboard with the wrapper you've been working on for some time (the 'out-of-process' approach changes this only marginally). I simply want to point out that the 'published interface' (i.e., the generated definectMatlab.m file) is an unnecessary step and should be removed; it is a distraction and not useful to the user base. Instead, the C++ interface should be used as a drop-in replacement for the older calllib approach.

Ah I see. Yes the 'published interface' is definitely just an intermediate step that I only use for debugging purposes for now. Eventually all the intermediate files will only be generated during the build process, and the C++ interface will be the only file visible to the user.

I just tested the current status and, on macOS, still don't get a running system. After regenerating all files (I made sure to remove the old install) and following the updated readme.md, I now get:

>> ctLoad()
Unable to load interface library: '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlabInterface.dylib'. Reason:
The specified module could not be found.
Ensure the C++ dependent libraries for the interface library are added to run-time path.

The library exists at this location! The new C++ ways apparently introduce some uncomfortable library dependencies that need to be resolved (I believe this is the same issue as the one you faced with CI). I tried launching MATLAB either the usual way or from within the conda environment, and it didn't make a difference.

On the upside, I am happy to see the environment gone!

I am still not happy about the published interface, but, at the moment, it is more important to get this to run.

PS: here's my full listing:

>> ctDir = '/work/GitHub/cantera';
>> ctIncludeDir = '/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/include';
>> ctLibDir = '/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/lib';
>> ctBuildInterface(ctDir, ctIncludeDir, ctLibDir);
Paths used in the build process:
Cantera Root: /work/GitHub/cantera
Include Directory: /opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/include
Header Directory: /opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/include/cantera/clib
Cantera Library: /opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/lib
Output Folder: /work/GitHub/cantera/interfaces/matlab_experimental/cantera
MEX configured to use 'Xcode Clang++' for C++ language compilation.
Deleted file '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/definectMatlab.m'.
C++ compiler set to 'Xcode Clang++'.
Definition file [definectMatlab.m](matlab: open('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/definectMatlab.m')) contains definitions for 351 constructs supported by MATLAB.
- 264 constructs are fully defined.
- 87 constructs partially defined and commented out.

To include the 87 undefined constructs in the interface, uncomment and complete the definitions in [definectMatlab.m](matlab: open('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/definectMatlab.m')).
To build the interface, call build(definectMatlab).
Building interface file 'ctMatlabInterface.dylib' for clib interface 'ctMatlab'.
Build Log:
/usr/bin/xcrun -sdk macosx26.0 clang++ -c -fno-common -arch arm64 -mmacosx-version-min=12.0 -fexceptions -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -fwrapv -ffp-contract=off  -fobjc-arc -std=c++14 -stdlib=libc++ -O2 -DNDEBUG   -I"/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/include" -I"/Applications/MATLAB_R2025a.app/extern/include"  "/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlabInterface.cpp" -o "/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlabInterface.o"

/usr/bin/xcrun -sdk macosx26.0 clang++ -Wl,-twolevel_namespace  -arch arm64 -mmacosx-version-min=12.0 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -framework Cocoa -bundle  -stdlib=libc++   "/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlabInterface.o"  "/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/lib/libcantera_shared.dylib" "/Applications/MATLAB_R2025a.app/extern/bin/maca64/libMatlabDataArray.dylib"  -Wl,-rpath,@loader_path/ -O   -o "/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlabInterface.dylib" -sectcreate __TEXT us_resources "/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab/ctMatlab.zip"


---
Interface file 'ctMatlabInterface.dylib' built in folder '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab'.

To use the library, add the interface file folder to the MATLAB path.
[addpath('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab')](matlab: internal.matlab.desktop.commandwindow.executeCommandForUser('addpath(''/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab'')'))
Execution mode 'ctMatlab' set to 'outofprocess'. To modify, call [clibConfiguration('ctMatlab','ExecutionMode','inprocess')](matlab: internal.matlab.desktop.commandwindow.executeCommandForUser('clibConfiguration(''ctMatlab'',''ExecutionMode'',''inprocess'')')).
 Copied 1 run-time library files to '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/cantera/ctMatlab'
    /opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/lib/libcantera_shared.dylib

 Run-time dependencies copied to interface library folder.

This problem should be fixed by now. By default MATLAB on MacOS does not set the correct DYLD_LIBRARY_PATH variables for an external process. The missing dependency is libMatlabDataArray.dylib.

Thanks, @ssun30. Almost there, the main issue I ran into is this one:

>> ctLoad()
Cantera 3.2.0a4 is ready for use (outofprocess mode).
>> cd test/matlab_experimental/
>> runMatlabInterfaceTests
Error using [matlab.unittest.internal.createTestSuite](matlab:matlab.lang.internal.introspective.errorDocCallback('matlab.unittest.internal.createTestSuite', '/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/+matlab/+unittest/+internal/createTestSuite.m', 21)) ([line 21](matlab: opentoline('/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/+matlab/+unittest/+internal/createTestSuite.m',21,0)))
Unable to create a test suite from /Volumes/Data/work/GitHub/cantera/test/matlab_experimental/test/matlab_experimental.

Error in [testsuite](matlab:matlab.lang.internal.introspective.errorDocCallback('testsuite', '/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/testsuite.m', 95)) ([line 95](matlab: opentoline('/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/testsuite.m',95,0)))
suite = matlab.unittest.internal.createTestSuite(tests, options);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in [runMatlabInterfaceTests](matlab:matlab.lang.internal.introspective.errorDocCallback('runMatlabInterfaceTests', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/runMatlabInterfaceTests.m', 5)) ([line 5](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/runMatlabInterfaceTests.m',5,0)))
suite = testsuite(testFolder);
        ^^^^^^^^^^^^^^^^^^^^^

PS: I spot-tested samples, and some ran 🎉 (although others didn't, e.g., diamond_cvd but that may be related to #1722?)

That was caused by that script not using the correct relative paths. Should be fixed now.

The diamond_cvd sample is unrelated to #1722 but because the legacy clib method surf_setCoverages not having a defined length of the surface coverage array. As such, ctEditLibraryDefinitions.m couldn't set the correct <SHAPE> parameter for the corresponding MATLAB function. The same goes for the getter method for surface coverages, and setter/getter for surface concentrations. These edge cases should no longer be the case with the generated cib.

Thanks, @ssun30. Almost there, the main issue I ran into is this one:

>> ctLoad()
Cantera 3.2.0a4 is ready for use (outofprocess mode).
>> cd test/matlab_experimental/
>> runMatlabInterfaceTests
Error using [matlab.unittest.internal.createTestSuite](matlab:matlab.lang.internal.introspective.errorDocCallback('matlab.unittest.internal.createTestSuite', '/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/+matlab/+unittest/+internal/createTestSuite.m', 21)) ([line 21](matlab: opentoline('/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/+matlab/+unittest/+internal/createTestSuite.m',21,0)))
Unable to create a test suite from /Volumes/Data/work/GitHub/cantera/test/matlab_experimental/test/matlab_experimental.

Error in [testsuite](matlab:matlab.lang.internal.introspective.errorDocCallback('testsuite', '/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/testsuite.m', 95)) ([line 95](matlab: opentoline('/Applications/MATLAB_R2025a.app/toolbox/matlab/testframework/unittest/core/testsuite.m',95,0)))
suite = matlab.unittest.internal.createTestSuite(tests, options);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error in [runMatlabInterfaceTests](matlab:matlab.lang.internal.introspective.errorDocCallback('runMatlabInterfaceTests', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/runMatlabInterfaceTests.m', 5)) ([line 5](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/runMatlabInterfaceTests.m',5,0)))
suite = testsuite(testFolder);
        ^^^^^^^^^^^^^^^^^^^^^

PS: I spot-tested samples, and some ran 🎉 (although others didn't, e.g., diamond_cvd but that may be related to #1722?)

That was caused by that script not using the correct relative paths. Should be fixed now.

The diamond_cvd sample is unrelated to #1722 but because the legacy clib method surf_setCoverages not having a defined length of the surface coverage array. As such, ctEditLibraryDefinitions.m couldn't set the correct <SHAPE> parameter for the corresponding MATLAB function. The same goes for the getter method for surface coverages, and setter/getter for surface concentrations. These edge cases should no longer be a concern with the generated cib (I tested the generated Clib and all arrays have defined lengths).

Making progress! The latest fix was successful for the test suite. There are three failed tests, though, when running locally:

>> runMatlabInterfaceTests
Running ctTestConstPressureReactor
Cantera 3.2.0a4 is ready for use (outofprocess mode).

================================================================================
ctTestConstPressureReactor/testReactorSurfaceType was filtered.
    Test Diagnostic: Skipped until Clib is ported to the generated version
[Details](matlab:matlab.automation.internal.displayToWebWindowAsText('PHN0cm9uZz5BbiBhc3N1bXB0aW9uIHdhcyBub3QgbWV0IGluIGN0VGVzdENvbnN0UHJlc3N1cmVSZWFjdG9yL3Rlc3RSZWFjdG9yU3VyZmFjZVR5cGUgYW5kIGl0IGZpbHRlcmVkIHRoZSByZW1haW5kZXIgb2YgdGhlIHRlc3QuPC9zdHJvbmc+CiAgICAtLS0tLS0tLS0tLS0tLS0tCiAgICBUZXN0IERpYWdub3N0aWM6CiAgICAtLS0tLS0tLS0tLS0tLS0tCiAgICBTa2lwcGVkIHVudGlsIENsaWIgaXMgcG9ydGVkIHRvIHRoZSBnZW5lcmF0ZWQgdmVyc2lvbgogICAgLS0tLS0tLS0tLS0tLS0tLS0tCiAgICBTdGFjayBJbmZvcm1hdGlvbjoKICAgIC0tLS0tLS0tLS0tLS0tLS0tLQogICAgSW4gPGEgaHJlZj0ibWF0bGFiOm9wZW50b2xpbmUoJy9Wb2x1bWVzL0RhdGEvd29yay9HaXRIdWIvY2FudGVyYS90ZXN0L21hdGxhYl9leHBlcmltZW50YWwvY3RUZXN0Q29uc3RQcmVzc3VyZVJlYWN0b3IubScsMTQ0LDEpIj4vVm9sdW1lcy9EYXRhL3dvcmsvR2l0SHViL2NhbnRlcmEvdGVzdC9tYXRsYWJfZXhwZXJpbWVudGFsL2N0VGVzdENvbnN0UHJlc3N1cmVSZWFjdG9yLm0gKGN0VGVzdENvbnN0UHJlc3N1cmVSZWFjdG9yLnRlc3RSZWFjdG9yU3VyZmFjZVR5cGUpIGF0IDE0NDwvYT4K','QXNzdW1wdGlvbkZhaWxlZDogY3RUZXN0Q29uc3RQcmVzc3VyZVJlYWN0b3IvdGVzdFJlYWN0b3JTdXJmYWNlVHlwZQ=='))
================================================================================
.
================================================================================
Error occurred in ctTestConstPressureReactor/testClosed and it did not run to completion.
    ---------
    Error ID:
    ---------
    'Cantera:ctError'
    --------------
    Error Details:
    --------------
    Error using [ctFunc](matlab:matlab.lang.internal.introspective.errorDocCallback('ctFunc', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m', 12)) ([line 12](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m',12,0)))
    
    *******************************************************************************
    CanteraError thrown by Application::findInputFile:
    
    Input file ../data/ch4_minimal.yaml not found in directories
    '.',
    '/usr/local/Caskroom/miniconda/base/envs/ct-test/share/cantera/data',
    '/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/share/cantera/data'
    
    To fix this problem, either:
        a) move the missing files into the local directory;
        b) define environment variable CANTERA_DATA to
             point to the directory containing the file.
    *******************************************************************************
    
    Error in [Solution](matlab:matlab.lang.internal.introspective.errorDocCallback('Solution', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m', 78)) ([line 78](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m',78,0)))
                    ID = ctFunc('soln_newSolution', src, name, transport_model);
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/makeReactors](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/makeReactors', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 40)) ([line 40](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',40,0)))
                self.gas = Solution(src, 'testConstPressureReactor');
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/testClosed](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/testClosed', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 153)) ([line 153](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',153,0)))
                self.makeReactors();
                ^^^^^^^^^^^^^^^^^^^^
================================================================================
.
================================================================================
Error occurred in ctTestConstPressureReactor/testWithHeatTransfer and it did not run to completion.
    ---------
    Error ID:
    ---------
    'Cantera:ctError'
    --------------
    Error Details:
    --------------
    Error using [ctFunc](matlab:matlab.lang.internal.introspective.errorDocCallback('ctFunc', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m', 12)) ([line 12](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m',12,0)))
    
    *******************************************************************************
    CanteraError thrown by Application::findInputFile:
    
    Input file ../data/ch4_minimal.yaml not found in directories
    '.',
    '/usr/local/Caskroom/miniconda/base/envs/ct-test/share/cantera/data',
    '/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/share/cantera/data'
    
    To fix this problem, either:
        a) move the missing files into the local directory;
        b) define environment variable CANTERA_DATA to
             point to the directory containing the file.
    *******************************************************************************
    
    Error in [Solution](matlab:matlab.lang.internal.introspective.errorDocCallback('Solution', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m', 78)) ([line 78](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m',78,0)))
                    ID = ctFunc('soln_newSolution', src, name, transport_model);
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/makeReactors](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/makeReactors', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 40)) ([line 40](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',40,0)))
                self.gas = Solution(src, 'testConstPressureReactor');
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/testWithHeatTransfer](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/testWithHeatTransfer', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 158)) ([line 158](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',158,0)))
                self.makeReactors('addQ', true);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
================================================================================
.
================================================================================
Error occurred in ctTestConstPressureReactor/testWithMdot and it did not run to completion.
    ---------
    Error ID:
    ---------
    'Cantera:ctError'
    --------------
    Error Details:
    --------------
    Error using [ctFunc](matlab:matlab.lang.internal.introspective.errorDocCallback('ctFunc', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m', 12)) ([line 12](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Utility/ctFunc.m',12,0)))
    
    *******************************************************************************
    CanteraError thrown by Application::findInputFile:
    
    Input file ../data/ch4_minimal.yaml not found in directories
    '.',
    '/usr/local/Caskroom/miniconda/base/envs/ct-test/share/cantera/data',
    '/opt/homebrew/Caskroom/miniforge/base/envs/cantera-dev/share/cantera/data'
    
    To fix this problem, either:
        a) move the missing files into the local directory;
        b) define environment variable CANTERA_DATA to
             point to the directory containing the file.
    *******************************************************************************
    
    Error in [Solution](matlab:matlab.lang.internal.introspective.errorDocCallback('Solution', '/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m', 78)) ([line 78](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/interfaces/matlab_experimental/Base/Solution.m',78,0)))
                    ID = ctFunc('soln_newSolution', src, name, transport_model);
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/makeReactors](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/makeReactors', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 40)) ([line 40](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',40,0)))
                self.gas = Solution(src, 'testConstPressureReactor');
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Error in [ctTestConstPressureReactor/testWithMdot](matlab:matlab.lang.internal.introspective.errorDocCallback('ctTestConstPressureReactor/testWithMdot', '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m', 163)) ([line 163](matlab: opentoline('/Volumes/Data/work/GitHub/cantera/test/matlab_experimental/ctTestConstPressureReactor.m',163,0)))
                self.makeReactors('addMdot', true);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
================================================================================
.
================================================================================
ctTestConstPressureReactor/testWithSurfaceReactions was filtered.
    Test Diagnostic: Skipped until Clib is ported to the generated version
[Details](matlab:matlab.automation.internal.displayToWebWindowAsText('PHN0cm9uZz5BbiBhc3N1bXB0aW9uIHdhcyBub3QgbWV0IGluIGN0VGVzdENvbnN0UHJlc3N1cmVSZWFjdG9yL3Rlc3RXaXRoU3VyZmFjZVJlYWN0aW9ucyBhbmQgaXQgZmlsdGVyZWQgdGhlIHJlbWFpbmRlciBvZiB0aGUgdGVzdC48L3N0cm9uZz4KICAgIC0tLS0tLS0tLS0tLS0tLS0KICAgIFRlc3QgRGlhZ25vc3RpYzoKICAgIC0tLS0tLS0tLS0tLS0tLS0KICAgIFNraXBwZWQgdW50aWwgQ2xpYiBpcyBwb3J0ZWQgdG8gdGhlIGdlbmVyYXRlZCB2ZXJzaW9uCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0KICAgIFN0YWNrIEluZm9ybWF0aW9uOgogICAgLS0tLS0tLS0tLS0tLS0tLS0tCiAgICBJbiA8YSBocmVmPSJtYXRsYWI6b3BlbnRvbGluZSgnL1ZvbHVtZXMvRGF0YS93b3JrL0dpdEh1Yi9jYW50ZXJhL3Rlc3QvbWF0bGFiX2V4cGVyaW1lbnRhbC9jdFRlc3RDb25zdFByZXNzdXJlUmVhY3Rvci5tJywxNjgsMSkiPi9Wb2x1bWVzL0RhdGEvd29yay9HaXRIdWIvY2FudGVyYS90ZXN0L21hdGxhYl9leHBlcmltZW50YWwvY3RUZXN0Q29uc3RQcmVzc3VyZVJlYWN0b3IubSAoY3RUZXN0Q29uc3RQcmVzc3VyZVJlYWN0b3IudGVzdFdpdGhTdXJmYWNlUmVhY3Rpb25zKSBhdCAxNjg8L2E+Cg==','QXNzdW1wdGlvbkZhaWxlZDogY3RUZXN0Q29uc3RQcmVzc3VyZVJlYWN0b3IvdGVzdFdpdGhTdXJmYWNlUmVhY3Rpb25z'))
================================================================================
.Cantera has been unloaded

Done ctTestConstPressureReactor

[...]

Totals:
   481 Passed, 3 Failed ([rerun](matlab:matlab.unittest.internal.rerunFailedTests('results','WxMJLrbzksUukDqaqNVBcW7qktw4UYQYmL6HPQ=='))), 31 Incomplete.
   32.932 seconds testing time.

>> pwd

ans =

    '/Volumes/Data/work/GitHub/cantera/test/matlab_experimental'

I wasn't able to reliably replicate this error. This test looks for a yaml data file in ../data which should've been added to MATLAB search path by ctTestSetUp. There are other tests that do the same thing and they ran without problems. I did get this error a couple of times before on MacOS and Windows but running the script again resolved it. This was why I originally had each unit test copying those test data files into the local folder. This should be more robust after we implement the generated clib since we can use the ct_addDataDirectories to directly add the test data directory.