Fix macOS libomp conflict properly instead of silencing it - #260
Open
fnachon wants to merge 9 commits into
Open
Conversation
Changes made to run without errors on the Mac MPS device: torch.autocast, number of devices and workers to use on M1-5 chips, workaround for CUDA-specific code, handling of float64 incompatibilities for MPS.
Replace hardcoded torch.autocast("cuda") with device-agnostic
device_type=tensor.device.type in confidence_utils, inverse_fold,
and writer modules introduced in the upstream merge.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Python pickle does not preserve RDKit atom-level SetProp values. When PyTorch DataLoader spawns worker processes (default num_workers=1 on macOS), self.canonicals is pickled and all atom 'name' properties are lost, causing KeyError in process_atom_features. Fix: load all required molecules directly from the moldir zip inside each get_sample() / get_feat() call instead of using the pickled self.canonicals. The moldir zip handle is cached per-process by _get_zipfile(), so there is no repeated I/O overhead. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ders - Disable pin_memory on MPS (unsupported, causes UserWarning) - Enable persistent_workers when num_workers > 0 (avoids repeated worker init overhead and the PL suggestion warning) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The README recommended export KMP_DUPLICATE_LIB_OK=TRUE for the "OMP: Error HannesStark#15: Initializing libomp.dylib, but found libomp.dylib already initialized" crash. That env var only silences OpenMP's duplicate-runtime safety check; it doesn't fix the actual conflict (torch and scikit-learn each bundle their own libomp.dylib), and can mask real correctness issues rather than just this crash. Add scripts/fix_macos_libomp.py, which repoints every duplicate libomp.dylib copy in site-packages at a single canonical one so only one OpenMP runtime is ever loaded, and point the README at it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README's macOS install instructions recommended
export KMP_DUPLICATE_LIB_OK=TRUEto work aroundOMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized(torch and scikit-learn each bundle their own copy oflibomp.dylib, and loading more than one into the same process trips OpenMP's safety check). That env var only silences the check — it doesn't fix the actual duplicate-runtime conflict, and per OpenMP's own docs it can mask real correctness issues, not just this crash.Adds
scripts/fix_macos_libomp.py, which repoints every duplicatelibomp.dylibcopy insite-packagesat a single canonical one so only one OpenMP runtime is ever loaded, and updates the README to point at it (documented as a post-install step, since it needs to inspect installed packages).Ported from the equivalent fix in fnachon/boltz, which hit the same conflict with the same dependencies (torch + scikit-learn).