Idaklu error

[akariwrynn]

Hi,
I was trying to use multiprocessing with my code but appreantly pybamm seems not compatible with both multiprocessing and multithreading since they both increase the time that it takes. Therefore, I am trying to use Idaklu where I have been trying to use the example code that is published :

import pybamm
import numpy as np

construct model

model = pybamm.lithium_ion.DFN()
geometry = model.default_geometry
param = model.default_parameter_values
param.process_model(model)
param.process_geometry(geometry)
n = 500 # control the complexity of the geometry (increases number of parameters)
var_pts = {"x_n": n, "x_s": n, "x_p": n, "r_n": round(n/10), "r_p": round(n/10)}
mesh = pybamm.Mesh(geometry, model.default_submesh_types, var_pts)
disc = pybamm.Discretisation(mesh, model.default_spatial_methods)
disc.process_model(model)
t_eval = np.linspace(0, 3600, 100)

solve using IDAKLU

options = {'num_threads': 1}
for _ in range(5):
klu_sol = pybamm.IDAKLUSolver(atol=1e-8, rtol=1e-8, options=options).solve(model, t_eval)
print(f"Solve time: {klu_sol.solve_time.value1000} msecs [{options['num_threads']} threads]")
options = {'num_threads': 4}
for _ in range(5):
klu_sol = pybamm.IDAKLUSolver(atol=1e-8, rtol=1e-8, options=options).solve(model, t_eval)
print(f"Solve time: {klu_sol.solve_time.value1000} msecs [{options['num_threads']} threads]")"

But I am getting this error "C:\vcpkg\buildtrees\casadi\src\ghtly-ship-e94fd05723.clean\casadi\core\serializing_stream.cpp:355: Assertion "load_version==v" failed:
DeSerialization of ProtoFunction failed. Object written in version 2 but can only read in version 1."

My python version is 3.11.3, pybamm is 23.5. How can I solve this or is there someone using multiprocessing or multithreading for pybamm simulations?

Thanks a lot,
Eren

[valentinsulzer]

@jsbrittain has been working on multiprocessing and might be able to help here. See #2644

[akariwrynn]

Hi,
I was trying to read that but since I am not very used to use github I just got confused. Does it work or it is still under review? Also, if possible can you share a code that it works therefore I can understand how it works?

Thanks a lot,
Eren

[jsbrittain]

@akariwrynn - Idaklu supports multithreading exactly as you have attempted through the num_threads parameter. The error that you are receiving looks similar to a recent issue that was raised in relation to the Idaklu solver more broadly (#3100 ), noting that this issue was closed after being resolved by the poster downgrading versions. @tinosulzer I suggest that this is something we reopen and follow-up on - I have a suspicion that there may be an incompatibility with the newer casadi libraries, and may relate specifically to those compiled for Mac silicon hardware (@akariwrynn can I ask what hardware you are running PyBaMM on?).

The other issue mentioned above (#2644 ) relates to GPU acceleration for the JAX solver and has not been reviewed yet so is still in development (if you really wanted to try it out you can find the relevant branch here: see https://github.com/jsbrittain/PyBaMM/tree/jax). Note that the JAX solver is inherently multi-threaded anyway for a single PyBaMM model, the changes made in #2644 provide an interface to allow multiple simulations to run at once given a set of parameters.

[agriyakhetarpal]

Hi @chmabaur, for some diagnostics; could you post your version of casadi, test whether your installation of PyBaMM contains the IDAKLU solver via pybamm.have_idaklu(), and post your error trace? Also, could you check if reinstalling PyBaMM fixes the issue just in case?

[chmabaur]

@agriyakhetarpal : It is a fresh installation on a new windows system. First installed pybamm 23.5 with pip, then upgraded to 23.9. Also tried to reinstall pybamm with pip install --force-reinstall pybamm, but still same issue.

pip show casadi
Name: casadi
Version: 3.6.4

import pybamm
pybamm.have_idaklu()
Out[2]: True
pybamm.__version__
Out[3]: '23.9'

Code to reproduce error:

import pybamm
import numpy as np

model = pybamm.lithium_ion.DFN()

# create geometry
geometry = model.default_geometry

# load parameter values and process model and geometry
param = model.default_parameter_values
param.process_model(model)
param.process_geometry(geometry)

# set mesh
var_pts = {"x_n": 50, "x_s": 50, "x_p": 50, "r_n": 20, "r_p": 20}
mesh = pybamm.Mesh(geometry, model.default_submesh_types, var_pts)

# discretise model
disc = pybamm.Discretisation(mesh, model.default_spatial_methods)
disc.process_model(model)

# solve model
t_eval = np.linspace(0, 3600, 100)

sol = pybamm.IDAKLUSolver(atol=1e-8, rtol=1e-8).solve(model, t_eval)

Error trace:

Traceback (most recent call last):

  File C:\Software\Python\Environments\pybamm_venv\lib\site-packages\spyder_kernels\py3compat.py:356 in compat_exec
    exec(code, globals, locals)

  File c:\users\user\untitled0.py:31
    sol = pybamm.IDAKLUSolver(atol=1e-8, rtol=1e-8).solve(model, t_eval)

  File C:\Software\Python\Environments\pybamm_venv\lib\site-packages\pybamm\solvers\base_solver.py:836 in solve
    self.set_up(model, model_inputs_list[0], t_eval)

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

RuntimeError: C:\vcpkg\buildtrees\casadi\src\ghtly-ship-e94fd05723.clean\casadi\core\serializing_stream.cpp:355: Assertion "load_version==v" failed:
DeSerialization of ProtoFunction failed. Object written in version 2 but can only read in version 1.

[agriyakhetarpal]

Thank you so much @chmabaur, this helps a lot.

@jsbrittain, I would propose we should either re-open #3100 (or rather open a new issue about this serialisation error for higher visibility) and examine the workflow logs for 23.9 to see if that can tell us anything about the wheels. On an installation from source it is still possible to re-compile SuiteSparse and SUNDIALS and subsequently IDAKLU – but having this error come up again in a pip-installed rendition of PyBaMM and in multiple places (there is some discussion on #3569) means we ought to give it a look

[jsbrittain]

@agriyakhetarpal I agree. I've reopened #3100 as it appears to be the same issue, but renamed it to explicitly reference the serialisation error.

[jsbrittain]

PS: I'll take a further look at #3100 and report back.