Skip to content

Conversation

@sito115
Copy link

@sito115 sito115 commented Oct 9, 2025

Currently, only "maci64" (presumably for Intel-based macOS systems) is listed under the Darwin architecture names in discovery.py. I have added the corresponding name to include Apple Silicon–based systems.

@john-hen
Copy link
Collaborator

Hi. That's not an oversight, but a deliberate omission. See issue #80.

Short recap: What's missing here is thorough testing and thinking through the implications of this scenario. Importantly, supporting a second CPU architecture (ARM) on the same platform (macOS). That's not something we do on the other platforms (Windows, Linux). At the very least, you should consider (and test, and comment on) what happens when both versions of Comsol are installed on the same macOS system.

Also, the issue cited above has been dormant for more than two years now. That makes me even less inclined to support it. I don't want to be stuck maintaining it when I don't have access to Comsol on macOS ARM. (Quite frankly, it's pure chance that I still have access to Comsol on any platform. Let's not forget that the license costs 5-digit dollar amounts every year. I'm obviously not paying that out of my own pocket just to keep some open-source project alive.) Somebody has to step up. Or publish their fork on PyPI, also good.

That's all a long way of saying that I'm not gonna flick this switch willy-nilly. How do you see this playing out?

@sito115
Copy link
Author

sito115 commented Oct 11, 2025

Hi, thank you for the detailed response.
I wasn’t aware that this issue had already been identified.

Understanding that conflicts can arise when multiple versions of Comsol are installed on the same macOS, it may be reasonable to leave things as they are. However, implementing a user-friendly message when a macOS system is detected could serve as a helpful intermediate solution. For example:

"No Comsol version for Apple Silicon was found. Consider adding 'macarm64' in discovery.py.
Note: ARM-based macOS is not maintained/tested in this module."

This would help users to fix ARM-related errors in discovery.py more quickly.

At the moment, I only have access to the ARM version of Comsol. While I’m not a professional developer, I would be happy to assist by running tests on macOS if needed.

@john-hen
Copy link
Collaborator

At the moment, I only have access to the ARM version of Comsol.

Is that because Comsol was pre-installed on the computer you use? I would like to know what the install experience is like. From what I gather, in Comsol 6.0 (or whatever was the first that supported ARM). users could pick between the Intel version and the (then still experimental) ARM version. I don't know if that's still the case with Comsol 6.3. The Comsol documentation does not say much on that topic.

@sito115
Copy link
Author

sito115 commented Oct 12, 2025

Yes, Comsol was pre-installed on the computer I’m using.
When I had access to a test license (version 6.3) for a Comsol training course, it appeared that only the ARM version was available for my computer. I recall this from a screenshot I took back then during the installation.
image

@john-hen
Copy link
Collaborator

john-hen commented Oct 12, 2025

Well, I guess you could have clicked on "macOS Intel" there, installed that instead, and it would have also worked (via Rosetta emulation).

But come to think of it, maybe we should go a similar route as the online Comsol installer: just look for an exact match of platform and architecture. That means a change to the logic in discovery.py though. Instead of trying each architecture in that list sequentially, as we do now.

Comsol used to also have an offline installer, an .iso disk image. And even before that, actual DVDs. But I'd say we no longer have to worry about that. And since the ARM version can be assumed to be stable now, there's little reason for people to install the Intel version when they're on an ARM Mac. Which wasn't the case when the first ARM Macs came out.

To run the test suite, you just do:

python tools/test.py --log

See the ReadMe's in the tests and tools folders for more details on that. Maybe post the output here, especially if tests fail. (They are all expected to pass, obviously.) There's currently a bug in JPype version 1.6.0 (jpype-project/jpype#1307) that makes one of the tests fail with the latest NumPy. But you can work around that by installing an older NumPy version with pip install "numpy<2.3".

@john-hen john-hen changed the title Add Apple Silicon to system architecture names. Support Apple Silicon system architecture Oct 12, 2025
@sito115
Copy link
Author

sito115 commented Oct 13, 2025

Hi,

But come to think of it, maybe we should go a similar route as the online Comsol installer: just look for an exact match of platform and architecture. That means a change to the logic in discovery.py though. Instead of trying each architecture in that list sequentially, as we do now.

This might be an interesting idea!

All tests passed when running test.py with the current changes in this PR.
test_results.log

There only appeared a texture warning in line 431:

[00:36.898] Running export node "image".
UNSUPPORTED (log once): POSSIBLE ISSUE: unit 1 GLD_TEXTURE_INDEX_1D is unloadable and bound to sampler type (Float) - using zero texture because texture unloadable```

@john-hen
Copy link
Collaborator

That's great news. Thanks for running the tests!

I'm not worried about the warning. Image exports on Linux would hang indefinitely until they fixed something in Comsol 6.3, and barely anyone noticed. And this is just a warning, the exported image probably is fine.

Okay, I'll mull it over for a bit, see how exactly I want to release this. But I think we're good to go here.

@john-hen
Copy link
Collaborator

Hey. I was wondering how we best detect the Apple Silicon architecture, but I can't test it for lack of an ARM-based Mac. Does this print macarm64 for you?

import platform

def detect_architecture() -> str:
    system    = platform.system()
    machine   = platform.machine()
    bits      = platform.architecture()[0]
    processor = platform.processor()
    if system == 'Windows' and machine == 'AMD64' and bits == '64bit':
        return 'win64'
    if system == 'Linux' and machine == 'x86_64' and bits == '64bit':
        return 'glnxa64'
    if system == 'Darwin' and processor == 'i386' and bits == '64bit':
        return 'maci64'
    if system == 'Darwin' and processor == 'arm':
        return 'macarm64'
    raise OSError('Did not recognize platform architecture.')

print(detect_architecture())

For macOS, I'm basing it on this Stack Overflow question: How to get architecture of running Python interpreter on MacOS with Apple Silicon. There's also: How to check if Python is running on an M1 mac, even under Rosetta. But my thinking is we only want the former, but not the latter. So that if anyone actually were to run Python under Rosetta, we'd assume they also want the Intel version of Comsol, despite being on a new Mac.

@sito115
Copy link
Author

sito115 commented Oct 17, 2025

Hi,
very nice that you are restructuring the platform detection! I am sure that many Apple users will be very thankful! 😄
I would agree with this assumption:

But my thinking is we only want the former, but not the latter. So that if anyone actually were to run Python under Rosetta, we'd assume they also want the Intel version of Comsol, despite being on a new Mac.

Indeed, when running detect_architecture() it returns macarm64.
Hope it helps!

@john-hen
Copy link
Collaborator

Superseded by #231 (just merged), but it includes your commit in this PR here.

@john-hen john-hen closed this Oct 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants