feat: Add Sovereign hybrid CPU/GPU dispatch for MPS acceleration - #10

Ho, ho! Super-exciting. I finally find a hot spare moment to code review just a smidgeon of this. Extreme apologies for the huge delay on my end here. We actually lost power in our local area due to what can only charitably be referred to as "a climactic event." And on Canada Day, too! Why must we have to live in the Clifi Timeline ? 😮‍💨

So... uh. This PR is obviously awesome (because extreme parallelization) but also kinda problematic. Tests are failing upfront without even a single unit or integration test getting a chance to run, which is the first indication that there might be badness afoot.

PyTorch: OHNOES

Indeed, I see immediate badness in changes to betse/science/math/finitediff.py:

import torch

So... uh. BETSE definitely can't be unconditionally importing PyTorch. PyTorch is huge and crazy. BETSE users under Windows and Linux won't benefit from PyTorch-specific parallelization, because this PR only applies to macOS. Right? I think, anyway. Importing PyTorch has huge implications. That's not generally something one does lightly. So, that needs a considerable rethink.

Possibly even more problematically, this PR isn't even requiring PyTorch properly as an optional or mandatory dependency. I do see that torch is being required by the requirements.txt file, but... that basically doesn't matter. Nobody uses requirements.txt files in 2026. Everyone should be using pyproject.toml, which is what BETSE currently does.

This means that PyTorch needs to be added as an optional or mandatory dependency to pyproject.toml. Note, however, that this is non-trivial. Why? Because:

• This should (probably) only be conditional on the current platform being macOS.
• PyTorch itself currently comes in five different flavors, depending on whether you want CUDA (and which version), ROCm, or CPU. I personally have no idea how to express a dependency on PyTorch in a generic manner that covers all three from pyproject.toml. Do you? It's probably not too hard. But it's probably harder than adding a dependency on most Python packages would be.

Betse Submodules: Totally Destroyed

So, uh... Something seems to have gone terribly wrong with your changes to core BETSE submodules like betse.science.cells, which has been totally destroyed. By "totally destroyed," I mean just that. The betse/science/cells.py submodule now starts with an erroneous git merge conflict header <<<<<<< HEAD, which obviously isn't valid Python. Attempting to import that submodule is now guaranteed to raise a SyntaxError from CPython at submodule importation time.

This is super-badness, bro. I am sadness emoji cat. 😿

Tests: Totally Not Right

So, tests are being added as top-level scripts (e.g., test_patch.py, test_toolbox.py). That's also totally wrong, unfortunately. Like most Python packages, BETSE uses pytest and tox to test. Unit tests thus need to be written as proper pytest-based tests inside the existing betse_test/ subdirectory – not as top-level scripts outside pytest and tox.

There's also tons of other unrelated cruft that's being injected into the top-level repository (e.g., betse_finder.py, find_preprocess.py, requirements.txt). All of those files should also be removed from this PR. They probably have no relevance. Probably. No idea. Definitely suspicious stuff, though.

tl;dr: UUUUUUUUUGGGGGH!!!!!!

We all had super-high hopes for this PR. Tragically, it looks like some pretty messed up LLM slop going on here. I usually love LLM slop. But this is a bit much even for traditional LLM slop. This PR literally breaks everything, including both the main codebase and our test suite.

I'm kinda inclined to immediately close this PR without merging anything. Sadly, everything here is unusable in its current state. I acknowledge, however, that:

• Closing this PR without merging anything could be seen as hostile. Definitely don't want to go there. I am trying to be nice. I try so hard, GitHub! 😂 -> 😭
• You're the first person to care about BETSE in a huge amount of time. Although this PR is probably unsalvageable, perhaps you can try repairing everything on your end and giving another PR a shot?

One caveat, though. If you do try repairing everything on your end, you must locally ensure that tests pass. Specifically, you must run:

1. pytest at the top-level of this repository.
2. tox at the top-level of this repository.

If either pytest or tox complain, stop and try again. But please avoid submitting another PR with failing tests. Tests passing is a hard prerequisite for any working GitHub PR. Right? That's kinda the first thing that absolutely must happen. And that isn't even happening here. I sigh so much. 😮‍💨