Skip to main content

How to Resolve Python "OMP: Error #15: Initializing libiomp5md.dll, but found mk2iomp5md.dll already initialized"

When working with scientific or numerical Python libraries (like NumPy, SciPy, scikit-learn, TensorFlow, PyTorch, often linked with Intel's Math Kernel Library - MKL), you might encounter a runtime error stating: OMP: Error #15: Initializing libiomp5md.dll, but found mk2iomp5md.dll already initialized. (The specific DLL names might vary slightly based on OS and versions). This error indicates a conflict where multiple, incompatible versions of the OpenMP runtime library (responsible for parallel processing) have been loaded into the same process.

This guide explains the cause of this conflict and provides solutions ranging from workarounds to addressing the root cause, particularly within Anaconda environments.

Understanding the Error: Conflicting OpenMP Runtimes​

OpenMP is a standard API for writing shared-memory parallel programs. Different compilers and libraries (like Intel MKL, system GCC/Clang) might provide their own implementations of the OpenMP runtime library (libiomp, libgomp, etc.).

The OMP: Error #15 occurs when your Python process, through different imported libraries or dependencies, ends up loading more than one of these OpenMP runtime libraries. For example, one library might be linked against Intel's libiomp5md.dll (often via MKL), while another might be linked against a different version or even a non-Intel OpenMP runtime (represented conceptually by mk2iomp5md.dll in the error message, though the second name might not be literal). The runtime detects this potentially problematic situation and halts execution by default.

This conflict is particularly common in Anaconda environments where packages from the default anaconda channel (often MKL-linked) might mix with packages from other channels like conda-forge (often linked against system compilers).

Why is This Dangerous? (Performance/Correctness)​

As the error message hint suggests, loading multiple OpenMP runtimes is problematic because:

  • Performance Degradation: The runtimes might compete for resources or create excessive overhead, slowing down parallel computations.
  • Incorrect Results: Different runtimes might manage threads or synchronization differently, potentially leading to subtle or overt errors in calculations.
  • Crashes: Unpredictable interactions between the runtimes can lead to program crashes.

Therefore, while a workaround exists, addressing the underlying conflict is generally safer and more reliable.

Solution 1: The Environment Variable Workaround (KMP_DUPLICATE_LIB_OK)​

The error message itself suggests an "unsafe, unsupported, undocumented workaround": setting the environment variable KMP_DUPLICATE_LIB_OK to TRUE. This tells the Intel OpenMP runtime (which often triggers this check) to simply ignore the presence of other OpenMP runtimes and attempt to continue execution.

You can set this variable within your Python script using the os module. Crucially, this must be done before importing the libraries that load the conflicting runtimes. The very top of your main script is the best place.

# main.py
import os

# ✅ Set the environment variable AT THE VERY TOP
os.environ['KMP_DUPLICATE_LIB_OK']='True'

# --- Now import potentially problematic libraries ---
import numpy as np
# import scipy
# import sklearn
# import tensorflow
# ... etc ...

# --- Rest of your code ---
print("KMP_DUPLICATE_LIB_OK set. Proceeding...")

# Example numpy operation
a = np.random.rand(1000, 1000)
b = np.linalg.svd(a)
print("NumPy operation completed.")

  • os.environ['KMP_DUPLICATE_LIB_OK']='True': Sets the variable for the current process and its children. Case might matter (TRUE is often seen, but True usually works).

Setting the Variable in the Shell (Linux/macOS/Windows)​

Alternatively, you can set the environment variable in your shell before running your Python script. The command depends on your shell:

  • Linux/macOS (Bash, Zsh): 
    export KMP_DUPLICATE_LIB_OK=True
    python your_script.py
  • Windows (Command Prompt - CMD): 
    set KMP_DUPLICATE_LIB_OK=True
    python your_script.py
  • Windows (PowerShell): 
    $env:KMP_DUPLICATE_LIB_OK="True" # Or try $env:KMP_DUPLICATE_LIB_OK=1
    python your_script.py

Important Warning About This Workaround​

As stated in the original error message and documentation, setting KMP_DUPLICATE_LIB_OK=TRUE is unsafe and unsupported. While it often allows the program to run, it does not fix the underlying library conflict. You risk silent incorrect results, crashes, or performance issues. Use this primarily as a temporary diagnostic tool or if you understand and accept the risks for your specific application. Addressing the root cause (Solution 2) is strongly preferred.

Solution 2: Addressing the Root Cause in Anaconda (nomkl)​

If you are using Anaconda or Miniconda, the conflict often arises from mixing MKL-linked packages (default channel) with non-MKL-linked packages (e.g., conda-forge). The nomkl package helps resolve this by installing versions of core libraries (NumPy, SciPy, etc.) that are not linked against MKL, forcing them to use a more consistent OpenMP runtime.

  1. Activate Your Conda Environment: 
    conda activate your_env_name
  2. Install nomkl and Reinstall Core Packages: Installing nomkl first influences subsequent package installations. 
    # Install nomkl FIRST - preferably from conda-forge for consistency
    conda install nomkl --channel conda-forge

    # Reinstall key numerical libraries - conda will now prefer non-MKL versions
    conda install numpy scipy pandas scikit-learn # Add other relevant packages
  3. (Optional but Recommended) Remove MKL Explicitly: Ensure MKL isn't lingering. 
    conda remove --force mkl mkl-service mkl_fft
  4. Test: Run your script again without setting KMP_DUPLICATE_LIB_OK. The error should hopefully be gone.
  • If Issues Persist: Sometimes, the environment needs a cleaner state. Consider creating a new conda environment, install nomkl first from conda-forge, and then install the rest of your packages. 
    conda deactivate
    conda create --name new_clean_env
    conda activate new_clean_env
    conda install nomkl --channel conda-forge
    conda install numpy scipy pandas scikit-learn python=3.x # etc.
    # pip install ... # For packages not on conda

Solution 3: Renaming/Deleting Conflicting DLLs (Use with Extreme Caution)​

This is a highly discouraged, last-resort method. It involves manually finding the libiomp5md.dll file (or similar conflicting file mentioned in the error) within your Anaconda or Python installation directories and renaming or deleting it.

  • Why it's risky: Deleting or renaming core library files can break the packages that depend on them (especially MKL-linked ones) or other parts of your system. It might fix this specific error but cause others.
  • Common Locations:
    • ~/anaconda3/lib/ (Linux/macOS)
    • ~/anaconda3/Library/bin/ (Windows/macOS?)
    • ~/anaconda3/envs/YOUR_ENV_NAME/lib/
    • ~/anaconda3/envs/YOUR_ENV_NAME/Library/bin/
    • C:\Users\YOUR_USER\Anaconda3\...\Library\bin\
  • Recommendation: If you attempt this, RENAME the file (e.g., to libiomp5md.dll.disabled) instead of deleting it, so you can restore it if needed.
note

Proceed with this method only if you understand the risks and other solutions have failed.

Choosing the Right Approach​

  1. Try the KMP_DUPLICATE_LIB_OK=True environment variable first (set in Python or Shell) as a quick test to see if it suppresses the error. Understand the risks if you leave it set.
  2. If using Anaconda/Conda, strongly prefer Solution 2 (nomkl) to fix the underlying library conflict. This is the safest and most reliable long-term solution in Conda environments.
  3. Renaming/deleting DLLs (Solution 3) should be a last resort due to the high risk of breaking your environment.

Conclusion​

The OMP: Error #15 signifies a dangerous conflict between multiple OpenMP runtime libraries loaded into your Python process, often involving Intel MKL.

  • The immediate workaround is setting the environment variable KMP_DUPLICATE_LIB_OK=True (either in your script before imports or in your shell), but this is unsafe and unsupported.
  • The preferred solution, especially in Anaconda environments, is to install nomkl and reinstall conflicting packages (numpy, scipy, etc.) to ensure consistent library linkage.
  • Manually renaming or deleting DLLs is highly risky and should be avoided if possible.

Prioritize addressing the root cause of the conflicting libraries for stable, correct, and performant execution.

Table of Contents