MacOS-only version with MPS support

[fnachon]

This is a MacOS-only version created with Claude.
Dependencies must be installed with Homebrew.
Xcode command Line Tools is necessary to compile Metal kernels

[dkoes]

This seems to replace CUDA with Metal, which is not what is desired. Can the choice of backend be a compile time switch?

[fnachon]

It may not be easy, but I can always try. I'll have a look at it and come back to you later.
Another option is to create a macOS-specific branch. Not ideal, but better than nothing.
Note that for gnina, I pointed to my fork for MacOS building.

[fnachon]

I restored CUDA compatibility alongside Metal, with a choice of backend at installation. So that you know, I couldn't test the CUDA side.

[phillipweinstock]

Hi @fnachon I traced your commits back from Gnina.
First off, you attached claudes brainstorming documentation so even if someone merged it in, it would drag all the junk in. Quite frankly this pull is not even possible to audit in the slightest. I commend you wanting to try and vibe code your way around CUDA, but even trained software engineers such as myself know that this isnt a viable solution.
Seeing as you don't want your work to goto waste, I suggest you keep your changes as a patch and follow this package upstream. Same with Gnina. That way you can continue working until someone else figures out how to swap out CUDA. Probably the best way to do it is first shim/wrap all CUDA logic into an abstracted interface, that way the backend becomes swappable instead of a mess of include statements and defines. Its still a very large job, your probably looking at a major rewrite of this library I.E the kind of thing the original authors would probably need a grant to do.

[phillipweinstock]

Actually I've just checked further. Just a little background I have not ever used CUDA before but just a glance at grid_maker.cpp Line 358, shows float3 datatypes everywhere + exposing CUDA datatypes via public facing API. Any serious effort to port this to metal or any other platform like HIPS (close to gold standard), will by definition not be backwards compatible a major architectural refactor is required.
Regarding CUDA datatypes, a quick step to start cleaning up the internals would be replacing the float3 and other CUDA specific data types with a abstracted Vec3 datatype.