PyBaMM: [Bug]: `casadi_interpolant_linear.dll` not found on Windows with IDAKLUSolver, fails when simulating a drive cycle using Interpolant

PyBaMM Version

24.1rc2

Python Version

3.10.11

Describe the bug

I want to simulate a drive cycle by passing an Interpolant function to the “Current function [A]” parameter. This however fails as casadi_interpolant_linear.dll is not found.

Steps to Reproduce

import pybamm
import numpy as np

model = pybamm.lithium_ion.DFN()
geometry = model.default_geometry
param = model.default_parameter_values

# Create interpolant
current_interpolant = pybamm.Interpolant(
    np.linspace(0, 5000, 50000),
    np.ones(50000)*0.7,
    pybamm.t
    )

# Set drive cycle
param.update({"Current function [A]": current_interpolant})

# Solve
solver_idaklu = pybamm.IDAKLUSolver(
    rtol=1e-8, atol=1e-8)

sim = pybamm.Simulation(
    model, parameter_values=param, solver=solver_idaklu)
solution_idaklu = sim.solve(calc_esoh=False)

Relevant log output

File C:\Software\Python\Environments\pybamm_venv\lib\site-packages\pybamm\solvers\idaklu_solver.py:439 in set_up
    rhs_algebraic = idaklu.generate_function(rhs_algebraic.serialize())

RuntimeError: C:\vcpkg\buildtrees\casadi\src\3.6.4-aa7d507b6b.clean\casadi\core\casadi_os.cpp:166: Assertion "handle!=nullptr" failed:
PluginInterface::load_plugin: Cannot load shared library 'casadi_interpolant_linear.dll': 
   (
    Searched directories: 1. casadipath from GlobalOptions
                          2. CASADIPATH env var
                          3. PATH env var (Windows)
                          4. LD_LIBRARY_PATH env var (Linux)
                          5. DYLD_LIBRARY_PATH env var (osx)
    A library may be 'not found' even if the file exists:
          * library is not compatible (different compiler/bitness)
          * the dependencies are not found
   )
  Tried '' :
    Error code (WIN32): 126
  Tried '.' :
    Error code (WIN32): 126

About this issue

Original URL
State: open
Created 5 months ago
Reactions: 1
Comments: 26 (26 by maintainers)

Most upvoted comments

@arjxn-py and I have some progress on this; nothing concrete and I think we are nowhere close to resolution yet. What we think with a now-updated perspective is that the changes in #3569 were, in fact, not what ended up causing the mess, since we looked at all the relevant compiled files one-by-one for various wheels and inspected their runtime search paths, all of them look fine. I have compiled new wheels from a branch on my fork in this run, here: https://github.com/agriyakhetarpal/PyBaMM/actions/runs/8032835499. This branch reverts certain changes from #3569, including those made to the CMakeLists.txt file and adds back the script that was earlier used to rewrite the Python-CasADi runtime search paths. It also adds delvewheel to patch the Windows wheels – something we weren’t doing earlier. It should be ready for a PR soon if we can get to the bottom of what the problem is and how it can be resolved.

Note that there is a problem with the import pybamm statement currently because of the dependencies typing-extensions and sympy being treated as required dependencies while not aptly declared to be so (see #3836) which should be resolved soon. With the wheels from the workflow run above, the problem is partially fixed – the wheels for Linux and macOS are now able to run the script, but only if CASADIPATH is set to point to the CasADi path in site-packages. There is no respite for the Windows build yet, unfortunately…

Previously (with the current PyPI wheels, that is), the script does not work even if CASADIPATH, PATH, LD_LIBRARY_PATH, etc. are set to the CasADi installation, so at least we are able to restore the required functionality with the above wheels on Linux and macOS.

@chmabaur, you had mentioned previously in that you received the same error for all 24.1 pre-releases and the final release in https://github.com/pybamm-team/PyBaMM/issues/3783#issuecomment-1916702884 – additionally, could you please test whether the PyPI wheels for PyBaMM v23.5 and v23.9 are able to run the above script and confirm? Also, does the above set of wheels from the link to the workflow run, with CASADIPATH set work?

I am unaware whether this is an issue coming from an incorrect repair for the wheels – neither does delocate seem to have any major functionality changes in its recent releases, nor does auditwheel.

@jsbrittain, what I think is happening here is that when we link CasADi to the IDAKLU target during the compilation of the extension module, it just tries to find libcasadi.so.3.7 (or libcasadi.3.7.dylib on macOS) and not any of the other shared libraries that the IDAKLU solver seems to depend on, such as ilbcasadi_interpolant_linear.so in this case. Is there a way to “convince” CMake to link the IDAKLU target against the rest of these files, i.e., those present in the site-packages/casadi folder? We shouldn’t need things like libalpaqa.1.0.0.dylib, or the MUMPS or IPOPT files because we are not interfacing those solvers, but maybe libcasadi_rootfinder_newton.3.7.dylib, libcasadi_sundials_common.3.7.dylib, etc. (most of the files matching the libcasadi-* pattern, perhaps) should be declared as dependencies for IDAKLU in CMakeLists.txt and then copied into the PyBaMM wheel. Would greatly appreciate your help whenever you have time to look into this!

Also, cc @Saransh-cpp: since this issue had revealed that the PyBaMM wheel is broken for v24.1 for users of all platforms and dependents (see https://github.com/pybop-team/PyBOP/pull/176), we had decided in the developer meeting on 19/02/2024 that once the issue gets fixed, a 24.1post1 patch release should be made; and published to PyPI as soon as possible – and in the longer term (maybe even before 24.5), we should start looking towards properly testing the wheel ahead of releasing it to users.

agriyakhetarpal on Feb 26, 2024

I wanted to post an update on this: based on the logs for https://github.com/pybop-team/PyBOP/pull/176 where the IDAKLU solver is getting added to PyBOP, this issue is not just applicable for Windows wheels but for Linux and macOS wheels too, and I think I have some progress.

I still haven’t been able to ascertain the cause of the issue, but it has something to do where the generate_function code (which is where the Python component of the IDAKLU solver starts to go through the generated CasADi code to pass it to the C++ component via bindings) looks for the CasADi symbols. I feel that the issue is coming from these lines, that I had added in #3569:

https://github.com/pybamm-team/PyBaMM/blob/4597143f49706f30d8b2c9ff22c5fae90612b77f/CMakeLists.txt#L89-L93

i.e., an incorrect configuration of the runtime search path for the compiled CasADi files (the RPATH could be retained, but INSTALL_RPATH_USE_LINK_PATH should have been set to FALSE instead).

I can try to revisit this issue later this week and rebuild the wheels without this configuration, but I have a strong hunch that reverting the suitable changes in #3569 (just this file, not the SuiteSparse and SUNDIALS fixes for their RPATHs) should fix the issue. This may not resolve the Windows error, however. (Does RPATH have a significance on Windows? I am unaware).

Another tidbit that might be unrelated, but, on a Windows machine I did try to copy all the .dll files from the CasADi site-packages directory folder into where the IDAKLU .pyd file exists inside the wheel (i.e., pybamm/solvers/idaklu/ and therefore the . path where CasADi searches for them). In this case, it successfully finds the casadi_interpolant_linear.dll file and the related files that it needs for its runtime dependencies, but the program exits with a segmentation fault similar to what @jsbrittain had received on a different attempt, though without no warnings or messages to stdout, just a blank line followed by termination.

Right now, a workaround is to build PyBaMM from source, where this issue does not seem to occur. This is appropriate for Linux and macOS, but for Windows it’s a bit tricky and the reference is in the publish_pypi.yml workflow where certain environment variables are provided as flags that are passed to setup.py (vcpkg and VS2022 are required too). Building from source on Windows may not fix it either as noted above, since we do not yet have a mechanism to repair the current wheels for that platform.

I think the lesson from this is to advocate for better testing for the wheels after they have been built. We don’t bundle the test-related configurations and files inside the wheel (see #3617 and the publicly-announced GSoC project for it this year), but to get around that we should download these wheels as artifacts and test all of them manually in a job that installs them and runs all of the files under tests/ and examples/ inside a virtual environment.

agriyakhetarpal on Feb 19, 2024

Makes sense, @jsbrittain. Should we post this to the new #casadi channel on the PyBaMM Slack so that the CasADi developers can be made aware of these build issues and therefore suggest potential fixes? If this is is something that’s broken on their end, then they could fix it and we could potentially have a simpler build process in the future.

P.S. My comment about removing the lib-prefixes was about exploring how to do so at build-time by possibly configuring CMake not to add those prefixes, not at post-build by renaming the files

agriyakhetarpal on Feb 5, 2024