Hi First of All, I am new to Antibodybuilder and was so amazed at this tool and how it worked wonders after I used this for my work, but had to report this bug (I presume) during running on my macos silicon M4 base chip.

WARNING: I have used AI to paraphrase the entire content so that it is easier for you guys to understand as english is not my first language.

Take Care. Cheers.

ABodyBuilder2 on macOS: "OMP: Error #15 ... libomp.dylib already initialized" (Abort trap: 6)

Tags: abodybuilder2, immunebuilder, openmp, macos, conda, pytorch, openmm, apple-silicon

Problem

On macOS, every ABodyBuilder2 command aborts at startup:

$ ABodyBuilder2 --version
OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked
into the program. ...
Abort trap: 6

Root cause (the common case on Mac)

ABodyBuilder2 (via ImmuneBuilder) depends on PyTorch. When torch is installed from PyPI (pip install torch, shows as pypi_0 in conda list), the wheel bundles its own copy of libomp.dylib inside site-packages/torch/lib/.

Your conda environment already provides a libomp.dylib (from llvm-openmp, pulled in by openmm, libopenblas, etc.). So the process tries to load two separate physical copies of the same LLVM OpenMP runtime, and OpenMP aborts to avoid undefined behavior — OMP: Error #15, then Abort trap: 6.

Note this is NOT the Intel-MKL (libiomp5) variant of Error #15 that most web results describe. Here there is no MKL at all — it is conda libomp vs torch's bundled libomp. The nomkl fix does nothing in this case.

Confirm you have this case

conda activate <your_abb2_env>
find "$CONDA_PREFIX" -name "libomp*.dylib" 2>/dev/null
conda list | grep -Ei "torch"

You have this exact problem if you see two libomp.dylib paths — one in <env>/lib/ and one in <env>/lib/python3.x/site-packages/torch/lib/ — and torch shows channel pypi.

Fix (recommended: deduplicate to one runtime)

Both files are the same LLVM OpenMP runtime, so replace torch's bundled copy with a symlink to the environment's copy. Then only one physical library ever loads. This is fully reversible:

conda activate <your_abb2_env>

TORCH_OMP="$CONDA_PREFIX/lib/python3.x/site-packages/torch/lib/libomp.dylib"
#                              ^^^ match your Python version, e.g. python3.14

mv "$TORCH_OMP" "$TORCH_OMP.bak"                      # back up (reversible)
ln -s "$CONDA_PREFIX/lib/libomp.dylib" "$TORCH_OMP"   # point at the env's libomp

ABodyBuilder2 -h                                      # runs, no OMP error

To undo: mv "$TORCH_OMP.bak" "$TORCH_OMP".

If import torch later throws a missing-symbol error (rare; only if the two libomp versions are very far apart), just restore the .bak. libomp is ABI-stable, so in practice this works even across version gaps.

Important: the symlink is overwritten by pip install --upgrade torch

A plain symlink lives inside site-packages/torch/lib/, so reinstalling or upgrading torch drops a fresh bundled libomp.dylib back in and the error returns. To make the fix survive torch upgrades, use the self-healing approach below.

Permanent fix (recommended): self-healing conda activate script

Have conda re-apply the symlink on every env activation. Even after a torch upgrade restores the bundled copy, the next conda activate silently re-fixes it. Run once:

mkdir -p "$CONDA_PREFIX/etc/conda/activate.d"
cat > "$CONDA_PREFIX/etc/conda/activate.d/zz_fix_libomp.sh" <<'EOF'
#!/bin/bash
# Dedupe torch's bundled libomp against the env's libomp (fixes OMP Error #15 on macOS)
for TORCH_OMP in "$CONDA_PREFIX"/lib/python3.*/site-packages/torch/lib/libomp.dylib; do
  [ -e "$TORCH_OMP" ] || continue
  if [ ! -L "$TORCH_OMP" ]; then
    mv "$TORCH_OMP" "$TORCH_OMP.bak" 2>/dev/null
    ln -sf "$CONDA_PREFIX/lib/libomp.dylib" "$TORCH_OMP"
  fi
done
EOF
chmod +x "$CONDA_PREFIX/etc/conda/activate.d/zz_fix_libomp.sh"

The script is idempotent: it does nothing if the symlink is already in place, and re-applies it if a torch upgrade brought the real file back. Test with:

conda deactivate && conda activate <your_abb2_env>
ABodyBuilder2 -h

Optionally also pin torch so an accidental pip install -U doesn't reintroduce the bundled library in the first place:

pip install "torch==2.12.0" "torchvision==0.27.0"

Alternative fix (link torch against the shared libomp natively)

Reinstall torch from conda-forge so it does not bundle its own runtime:

pip uninstall torch torchvision
conda install -c conda-forge pytorch torchvision

Caveat: on bleeding-edge Python (3.13/3.14) or very new torch versions, conda-forge may not yet have matching builds, which can force a painful or impossible solve. If you are on such a setup, prefer the symlink fix above.

Last resort (accept numerical risk)

export KMP_DUPLICATE_LIB_OK=TRUE

Because both runtimes here are the same LLVM libomp, this is less dangerous than in the MKL-clash case — but the OpenMP project still labels it unsafe and it can produce silently incorrect results. Prefer the symlink fix for anything you publish.

Summary

The crash is a duplicate-OpenMP-runtime conflict caused by a pip-installed PyTorch wheel bundling its own libomp.dylib alongside conda's llvm-openmp. Symlinking torch's copy to the environment's single libomp.dylib resolves it cleanly and reversibly, with no need for the unsafe KMP_DUPLICATE_LIB_OK workaround.