OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5md.dll already initialized

The error#

OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5md.dll already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/

The process usually exits right after — in Jupyter, the kernel dies with no traceback.

What it means#

OpenMP is the threading runtime that parallelises numeric libraries. Exactly one copy may live in a process. Two of your packages each brought their own — typically Intel MKL's copy (via conda numpy/scipy) and PyTorch's copy (via pip) — and the second initialisation aborts. The hint's warning deserves respect: with two runtimes, even runs that survive can compute wrong numbers quietly.

Why it happens#

Mixed package sources in one environment. Conda's defaults channel builds numpy against MKL, which bundles libiomp5; pip's torch wheels carry their own OpenMP. Import both and the collision is mechanical. Windows conda environments are the classic host, but macOS and Linux see it too.

How to fix it#

1. Rebuild the environment with one source for the compiled stack. The real fix.

conda create -n ml python=3.12
conda activate ml
pip install torch numpy pandas scikit-learn

All-pip in a fresh environment is the simplest consistent choice. All-conda-forge is equally valid:

conda create -n ml -c conda-forge python=3.12 pytorch numpy pandas

The rule either way: compiled packages (numpy, scipy, torch, opencv) come from one installer, not a mixture.

2. The environment-variable workaround — use knowingly, temporarily.

import os
os.environ["KMP_DUPLICATE_LIB_OK"] = "TRUE"   # before importing numpy/torch

Intel's own text calls this unsafe, and "silently produce incorrect results" is a possibility to take at face value. Acceptable to finish today's exploration; unacceptable underneath results you publish, models you ship, or numbers anyone will trust. Schedule fix 1.

3. Identify the colliding pair when unsure.

conda list | grep -E "numpy|mkl|torch"

mkl from defaults alongside a pip torch is the signature. Replacing the MKL numpy (conda install -c conda-forge numpy or pip install numpy after removing conda's) also resolves it, but partial swaps invite the next inconsistency — the fresh environment is cleaner.

How to prevent it#

Adopt a per-environment policy — "pip for everything" or "conda-forge for everything, pip only for pure-Python" — and write it in the project README. When a tutorial says conda install and your environment is pip-based (or vice versa), translate rather than obey.

Related errors#

• The kernel appears to have died — how this error looks from inside Jupyter
• ImportError: DLL load failed — the other mixed-environment failure on Windows
• Solving environment: failed (conda)