Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Pybamm does not simulate experiment steps more than 24 hours #4155

Closed
aabills opened this issue Jun 7, 2024 · 2 comments
Closed

[Bug]: Pybamm does not simulate experiment steps more than 24 hours #4155

aabills opened this issue Jun 7, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@aabills
Copy link
Contributor

aabills commented Jun 7, 2024

PyBaMM Version

develop

Python Version

3.11

Describe the bug

If a user runs an experiment step without specifying a duration that should last more than 24 hours, it only runs for 24 hours. This is expected behavior given

return 24 * 3600 # 24 hours in seconds
, and I recognize that a default max time is probably necessary (not sure if the solvers can take ∞ as the max time 😃), but I think 24 hours is pretty short for a default duration when battery lifetimes are often measured in years and characterization tests (e.g. C/100 pseudo-OCV) that last longer than 24 hours are not unheard of.

The real issue here is that the code is doing something different than what a reasonable person would expect given a reasonable input, and I think that if a step is terminated due to a non-user specified action such as this, the code should throw a warning or something rather than silently not doing what the user specified. It does so when it hits voltage cutoffs etc.

Steps to Reproduce

import pybamm
model = pybamm.lithium_ion.DFN()
experiment = pybamm.Experiment(["Discharge at C/100 until 2.5 V"])
sim = pybamm.Simulation(model, experiment=experiment)
sol = sim.solve(initial_soc=1)

Relevant log output

No response

@aabills aabills added the bug Something isn't working label Jun 7, 2024
@valentinsulzer
Copy link
Member

Yeah we should definitely change this. The easiest fix is to calculate a better default duration for steps that are constant C-rate or constant current. That should catch most case, and a "rest" should require a duration to avoid division by zero.

@kratman
Copy link
Contributor

kratman commented Jun 28, 2024

Since there is a larger discussion of this topic in #4224, I am going to close this one for now

@kratman kratman closed this as completed Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants