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

Add heat sources corresponding to voltage loss from open-circuit potential hysteresis model #3867

Open
ejfdickinson opened this issue Mar 5, 2024 · 2 comments

Comments

@ejfdickinson
Copy link

Problem

The existing current sigmoid open-circuit potential hysteresis model, as well as planned extensions (#3375), make the value of the open-circuit potential a current-dependent quantity.

This means that there is a voltage difference between charge and discharge, even at negligible current. In a round-trip discharge followed by charge back to the initial SOC, more electrical work is done on the cell to charge it than is extracted from discharging it. A corresponding amount of energy must be dissipated from the system to obey overall conservation of energy. This "area inside the hysteresis loop" is familiar as a dissipation energy from mechanical hysteresis.

Because PyBaMM derives all electrochemical heating from overpotential with respect to the open-circuit potential, these losses are not included in the electrochemical heat source generated from the base thermal model.

Fix

An additional contribution to the irreversible electrochemical heating should be added to the thermal model, when a hysteresis model is used for OCP:

Q_rxn_hyst = a_j_[p/n] * (ocp_[p/n] - ocp_[p/n]_ave)

Here ocp_[p/n]_ave is a lithiation-dependent but current-independent quantity. A reasonable default would be the mean of the lithiation/delithiation hysteresis branches, in which case the dissipated heat will be 50% distributed between the lithiation and delithiation directions, but there is no particular physical reason why this should be the case.

@rtimms
Copy link
Contributor

rtimms commented Mar 6, 2024

Thanks @ejfdickinson, we have previously done some work on this and allowed an additional parameter for the “average” OCP (not yet merged into pybamm). Would you agree this is a sensible approach so the user can decide how to handle this?

@ejfdickinson
Copy link
Author

Yes @rtimms, I think that would be a good approach to allow sufficient user control, and maybe a judicious default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants