[MATLAB] Add multi-OS MATLAB test workflows to CI by ssun30 · Pull Request #1974 · Cantera/cantera

ssun30 · 2025-09-11T03:31:34Z

Changes proposed in this pull request

Run MATLAB tests in CI for Ubuntu 22.02/24.02, MacOS 13/14/15, and Windows 2022/2025.

Checklist

The pull request includes a clear description of this code change
Commit messages have short titles and reference relevant issues
Build passes (scons build & scons test) and unit tests address code coverage
Style & formatting of contributed code follows contributing guidelines
The pull request is ready for review

ischoegl

I'd prefer utilizing runners that build on previously compiled code within a single matrix job, similar to the approach taken by the .NET runners. Of course, this requires the generated CLib.

ischoegl

@ssun30 ... now that #1997 is merged (🎉), I believe it's possible to directly adopt the approach from .NET, which avoids recompilation, as you can download shared libraries and doxygen XML from artifacts.

ischoegl · 2025-11-03T15:59:00Z

Finally got the MATLAB matrix job to run with artifacts (🎉) - turned out to be a little more complicated than .NET, as I had to resolve some naming issues on Linux/macOS, and use a Windows DLL that was compiled outside of conda. A couple of caveats:

The failure on macOS-14 is odd, as I don't see it on my machine
The failure on ubuntu-22.04 appears for an example that is set up incorrectly; this example saw some work in Matlab papercuts #2031, so a merge may fix this (the flow domain was set up incorrectly).
The timeout on windows-2025 is linked to significant overhead of the outofprocess mode (see some diagnostics provided by @ssun30 here: [MATLAB] Migrate to generated Clib #1997 (comment)). It is still curious that the overall run takes more than 4 times longer than on macOS. Fwiw, the plug_flow_reactor.m example takes about 30 minutes on Windows by itself (and around 5 minutes on macOS).

Regarding slow samples, it appears that the tagging with Slow does not skip the tests (the test job bypasses this).

ischoegl · 2025-11-03T19:26:36Z

@speth ... after rebasing to switch to the generated CLib and updating the CI logic, I believe this is actually ready (I updated this PR, which was originally opened by @ssun30; the initial work pointed in a lot of the right directions).

I believe that I found a happy middle ground for MATLAB testing - run examples on macOS and skip them for other OS's. The outofprocess mode is slowing some of the MATLAB examples down a lot, but this is beyond the scope of this PR. Long-term, it is likely best to test samples separately from unit testing (i.e., same as we already do on Python), but this is likewise beyond the scope.

PS: I pushed some simplifications

ischoegl

Had to go back and fix an issue with a runner failing silently. Based on #2030, I further added more MATLAB versions to the tests. R2024a/b and R2025a work, but R2023b failed. Fwiw, the tests with issues reported in #2034 are now disabled.

The inclusion of older MATLAB versions surfaced another issue caused by Linux glibc, see #1935.

speth

Thanks, @ischoegl and @ssun30, I think it's good to have this more comprehensive testing. My suggestions here are mainly in the hope of simplifying a few things.

.github/workflows/main.yml

speth · 2025-11-04T19:18:53Z

.github/workflows/main.yml

+    - name: Run tests and examples (macOS)
+      uses: matlab-actions/run-tests@a80b208946040c701ae65c1bce73ba7ec4810757 # v2.1.2
+      with:
+        select-by-folder: test/matlab_experimental
+      if: runner.os == 'macOS'


Given the macOS package doesn't suffer from library compatibility issues (at least as it's built in this CI process), can we do this run using the inprocess mode?

This is an excellent point, but I'd prefer to handle this in a follow-up PR - I had created #2034 for that reason. It should be addressed for any usage, not just the CI.

speth · 2025-11-05T14:50:32Z

.github/workflows/main.yml

+    - name: Set LD_PRELOAD environment variable for MATLAB (Linux)
+      run: |
+        LIB_STDCXX=$(ldconfig -p | grep libstdc++.so.6 | awk '{print $4}' | head -n 1)
+        LIB_OPENBLAS=$(ldconfig -p | grep libopenblas.so.0 | awk '{print $4}' | head -n 1)
+        LIB_LAPACK=$(ldconfig -p | grep liblapack.so.3 | awk '{print $4}' | head -n 1)
+        echo "LD_PRELOAD=$LIB_STDCXX:$LIB_OPENBLAS:$LIB_LAPACK" >> $GITHUB_ENV


Is this still necessary, with the outofprocess mode available on Linux (even with its performance limitations)? If this is still required, then we haven't solved any of the library compatibility problems.

I don't know. Again, I'd prefer to handle this in a follow up that focuses on LD_PRELOAD - see new issue #2035.

speth · 2025-11-05T14:52:46Z

.github/workflows/main.yml

+    - name: Create library symlinks (Linux)
+      working-directory: build/lib
+      run: |
+        ln -s libcantera_shared.so libcantera_shared.so.3.2.0
+        ln -s libcantera_shared.so.3.2.0 libcantera_shared.so.3


Why are these symlinks required? Can't the Matlab interface just load the unversioned library?

MATLAB is unable to resolve these. It requires libcantera_shared.3.2.0.dylib for macOS and libcantera_shared.so.3 for Linux. This is the reason why there libraries need to be resolved by extra logic. Took me a while to figure out why @ssun30 had introduced this logic - I updated in the hope to make it easier to follow.

speth · 2025-11-05T15:08:19Z

interfaces/matlab_experimental/Utility/ctLib.m

+
+        scores = arrayfun(@(f) versionScore(f.name), files);
+        hasVersion = scores > 0;
+        if any(hasVersion)
+            [~, idx] = max(scores);
+            str = string(fullfile(libDir, files(idx).name));
        else


I realize this was a preexisitng condition, but I think this mechanism of interacting with the versioned shared libraries is completely ineffective. There is nothing to make sure that the Matlab toolbox corresponds to the version of libcantera that is found here. In the absence of a more robust mechanism for this, I would suggest just taking the simple approach and linking to the unversioned library name.

I also have no idea what a version "score" is, but that's sort of a moot point compared to the larger issue here.

It's targeting a different purpose - making sure that MATLAB finds a library that it is able to load. I'll add a comment to the version score (in effect, a way to ensure that we can sort version numbers according to integers).

Ensuring that libcantera matches would have to be tacked in ctLoad. Once we can access ctVersion from the shared library, it can be checked.

test/matlab_experimental/ctTestSamples.m

Co-authored-by: ischoegl <ischoegl@lsu.edu> Combines: - [CI] Added multi-OS MATLAB test workflows - [CI] Consolidated multi-OS MATLAB tests into one - Update to use artifacts for testing

ischoegl · 2025-11-05T16:57:52Z

Thanks, @ischoegl and @ssun30, I think it's good to have this more comprehensive testing. My suggestions here are mainly in the hope of simplifying a few things.

Thanks for the review! I took care of the straightforward suggestions. Regarding simplifications, it appears that some of the apparently complex functions are required to make things run. I had already opened #2034 and #2035 to track associated issues.

I'd prefer to push inprocess and LD_PRELOAD to follow-up PRs. When picking up @ssun30's work here, my main hope was to ensure that the generated CLib works on multiple OSs while using artifacts rather than recompiling from scratch. That would allow things to move to #2031, which will be my last MATLAB contribution before the final 3.2.0 release.

speth

No further comments.

ischoegl added the Matlab label Sep 11, 2025

ischoegl reviewed Sep 11, 2025

View reviewed changes

ssun30 force-pushed the matlab_installations branch from 46bb57e to dbdf45d Compare September 12, 2025 04:08

ischoegl reviewed Oct 27, 2025

View reviewed changes

ischoegl force-pushed the matlab_installations branch 26 times, most recently from b2c110a to 5d6cc8b Compare November 3, 2025 12:38

ischoegl force-pushed the matlab_installations branch 4 times, most recently from 3b904d9 to 665b5b1 Compare November 3, 2025 18:36

ischoegl requested a review from a team November 3, 2025 19:27

ischoegl force-pushed the matlab_installations branch from 665b5b1 to 92e4417 Compare November 3, 2025 23:45

This was referenced Nov 4, 2025

Issue with ctLoad on MacOS #2030

Closed

MATLAB's outofprocess mode has massive overhead #2034

Open

Matlab papercuts #2031

Merged

ischoegl force-pushed the matlab_installations branch 3 times, most recently from b531d40 to 23c9a4e Compare November 5, 2025 03:37

ischoegl reviewed Nov 5, 2025

View reviewed changes

ischoegl mentioned this pull request Nov 5, 2025

Older MATLAB fails for newer Linux glibc #2035

Open

ischoegl force-pushed the matlab_installations branch 4 times, most recently from 3c118d9 to 127b444 Compare November 5, 2025 12:33

speth requested changes Nov 5, 2025

View reviewed changes

ischoegl and others added 4 commits November 5, 2025 10:12

[MATLAB] Fix unversioned library names

ad231fa

[CI] Added multi-OS MATLAB test workflows

63a29d5

Co-authored-by: ischoegl <ischoegl@lsu.edu> Combines: - [CI] Added multi-OS MATLAB test workflows - [CI] Consolidated multi-OS MATLAB tests into one - Update to use artifacts for testing

[unittest] Disable slow examples in MATLAB unit test

b0921f8

[CI] Test alternative MATLAB versions

a68ab13

ischoegl force-pushed the matlab_installations branch from 127b444 to a68ab13 Compare November 5, 2025 16:12

ischoegl requested a review from speth November 5, 2025 16:58

speth approved these changes Nov 5, 2025

View reviewed changes

ischoegl merged commit aaf11b4 into Cantera:main Nov 5, 2025
59 of 61 checks passed

Uh oh!

Conversation

ssun30 commented Sep 11, 2025 • edited by ischoegl Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ischoegl left a comment

Choose a reason for hiding this comment

Uh oh!

ischoegl left a comment

Choose a reason for hiding this comment

Uh oh!

ischoegl commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ischoegl commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ischoegl left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

speth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

speth Nov 4, 2025

Choose a reason for hiding this comment

Uh oh!

ischoegl Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

speth Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ischoegl Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

speth Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ischoegl Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

speth Nov 5, 2025

Choose a reason for hiding this comment

Uh oh!

ischoegl Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ischoegl commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

speth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ssun30 commented Sep 11, 2025 •

edited by ischoegl

Loading

ischoegl commented Nov 3, 2025 •

edited

Loading

ischoegl commented Nov 3, 2025 •

edited

Loading

ischoegl left a comment •

edited

Loading

ischoegl Nov 5, 2025 •

edited

Loading

ischoegl commented Nov 5, 2025 •

edited

Loading