PyBaMM: [Bug]: IDAKLU / casadi serialization error - Object written in version 2 but can only read in version 1
PyBaMM Version
23.4.1
Python Version
3.9
Describe the bug
RuntimeError:C:..\casadi\core\serialization_stream.cpp:355:Assertion"load_version==v" failed:ProtoFunction failed. Object written in version 2 but can only read in version 1.
Steps to Reproduce
import pybamm
import numpy as np
model = pybamm.lithium_ion.SPM()
geometry = model.default_geometry
param = model.default_parameter_values
param.process_model(model)
param.process_geometry(geometry)
mesh = pybamm.Mesh(geometry,model.default_submesh_types,model.default_var_pts)
disc = pybamm.Discretisation(mesh,model.default_spatial_methods)
disc.process_model(model)
t_eval = np.linspace(0,3600,100)
if pybamm.have_idaklu():
klu_sol = pybamm.IDAKLUSolver(atol=1e-8,rtol=1e-8).solve(model,t_eval)
plot = pybamm.Quickplot(klu_sol)
plot.dynamic_plot()
Relevant log output
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 17 (15 by maintainers)
Commits related to this issue
- #3558 #3100 keep equal `casadi` dependency versions — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 7 months ago
- #3558 #3100 Don't use a default path to search for alternative `casadi` installations Co-Authored-By: jsbrittain <98161205+jsbrittain@users.noreply.github.com> — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 7 months ago
- #3100 Try Python `casadi` 3.6.4 for Windows wheels — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 7 months ago
- #3100 use vcpkg registry fork with casadi 3.6.4 — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 7 months ago
- Update to `casadi` `3.6.4` release See https://github.com/pybamm-team/PyBaMM/issues/3100/ for more details and discussion. This fixes the serialisation error coming from a CasADi ProtoFunction which... — committed to pybamm-team/casadi-vcpkg-registry by agriyakhetarpal 6 months ago
- Update git-tree for `casadi` `3.6.4` version bump See https://github.com/pybamm-team/PyBaMM/issues/3100/ for more details. This commti updates the git-tree to accommodate the version bump to `casadi... — committed to pybamm-team/casadi-vcpkg-registry by agriyakhetarpal 6 months ago
- #3100 bump `vcpkg` baseline for `casadi` `3.6.4` — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 6 months ago
- #3100 #3193 Add note for keeping `casadi` version in sync — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal 6 months ago
@jsbrittain @agriyakhetarpal The
CMakeLists.txtfix works for me too!I think I may have resolved the install problem by editing this line of
CMakeLists.txtto readfind_package(casadi CONFIG PATHS ${CASADI_DIR} REQUIRED NO_DEFAULT_PATH)(i.e. addNO_DEFAULT_PATH). I believe it was previously still checking system paths forcasadifirst, even after locating thesite-packagesversion. @pipliggins could you check this on your machine as-well please? @agriyakhetarpal If we can confirm this it would be worth adding to your PR #3569 .@agriyakhetarpal Thanks a lot for your efforts to solve this issue! I have tested both wheel files in separate virtual environments on Windows for python version 3.9. I am glad to say that in both cases the serialization error disappeared.
I am not able to follow your discussions above, but I hope it is ok that
pip showprints thecasadi version 3.6.4in both cases.I haven’t tried it with the latest
casadirelease yet since they don’t seem to provide any minor version compatibility of sorts (based on the many, many changes between3.6.3and3.6.4as noted in the release notes); but there should be no harm in trying that—I will update my fork of the registry again, try both the Python and vcpkg casadi and get back to this—maybe they fixed this on their end. I had chosen3.6.3specifically to synchronise the versions for the build-time and run-time dependencies, but I supposepipdownloads the latest version anyway unless we don’t pin them.I’m having some trouble recreating this issue, even with the specific verison of PyBaMM and python mentioned, but I do think I know where the problem is coming from.
The idaklu solver has a Python component and a C++ component, both of which link to casadi. The problem appears to be that under certain circumstances these two components seem to be getting out-of-sync with each other, causing the above reported serialisation error. This doesn’t typically happen since both components usually link to the same libraries which are downloaded as part of the PyBaMM install.
Simply rerunning the install procedure on the latest version of PyBaMM should be enough to update PyBaMM and resolve this. But if that doesn’t work then I would recommend performing a clean install of PyBaMM, i.e. remove the previous version first, which removes any compiled idaklu code, allowing a fresh install to compile and link using the provided libraries.
If that still doesn’t work then it is possible that there are environment variables pointing to a separate version of casadi on the computer (which could be getting picked up during installation) - in that case the user can remove or upgrade that version of casadi to match the version provided by PyBaMM, and then rerun the PyBaMM install scripts.
As a side note, this specific problem seems isolated to updates in casadi’s serialization format (which are not likely to change that often). I can’t suggest too much more without a reliable test-case. The error thrown by casadi (‘RuntimeError’) is quite generic so intercepting it in an attempt to provide a more directed set of instructions to the user may not be reliable. On top of that v23.4.1 still used tox, so the whole install system has been overhauled since then.
I think the best thing to do at this point is to close this issue, noting the above, and refer back in the future if we run into similar problems again.