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

active material volume fraction calculation for bpx files produces incorrect volume fractions #4265

Closed
dion-w opened this issue Jul 15, 2024 Discussed in #4241 · 3 comments

Comments

@dion-w
Copy link
Contributor

dion-w commented Jul 15, 2024

Hello, i found out that for bpx files the active material volume fraction (eps_am) is calculated from the specific surface area (a_s) via the equation via

a_s = 3 * eps_am / R_p

For the specific surface area in the P2D model it is already assumed that all particles are spheres. This may be true for electrode materials such as NMC but not for flake-like graphite. The true specific surface area for graphite is way higher than for spheres. Under certain circumstances this may lead to a case where the Active material volume fraction + porosity are bigger than one. Also electrodes typically use binder. Characterizing the electrode area experimentally would potentially lead to lower surface area, because reaction surfaces are blocked by binder, which would then lead to lower active material volume fraction which makes no sense in my opinion.
I think in this case, although also incorrect, it makes more sense to calculate the active material surface area just as either 1-porosity or add an approximated binder term in the bpx file. The way, as it currently is, only leads to situtations where porosity + eps_am are bigger than one.

So what do you think?

Discussed in #4241

Originally posted by dion-w July 4, 2024
Hello everyone,
I'm using a bpx file to start pybamm. I wanted to check whether the exchanged capacity between electrodes (i call it reversible electrode capacity for now) is the same, that means that the same amount of capacity leaves one electrode and enters the other. I tried to calculate it with the volume, the electrode area and the active material volume fraction as 1-porosity as the porosity is the only value that i get from the bpx file. This though gets me different reversible electrode capacities. I checked the exchanged number of moles and these were the same. I simulated a C/100 discharge with the bpx-file and saw that the active material volume fraction and the porosity of each electrode don't add up to one. They only add up to 0.94. I tried another bpx file, but here porosity and active material fraction also don't add up to one or even go above 1.

Could anyone tell me how the active material volume fraction is calculated from the porosity when using a bpx file?

The bpx file i used is attached.
nmc_pouch_cell_BPX.json

@ejfdickinson
Copy link

@dion-w Thank you for the feedback!

I think this belongs as a feedback / issue to BPX. I believe that PyBaMM is implementing BPX faithfully, but the BPX standard embeds some conscious approximations that can be overly simplistic or misleading for the reasons that @dion-w describes.

See also: FaradayInstitution/BPX#41

@rtimms Should we move this issue wholesale to the BPX repo?

@ejfdickinson
Copy link

@dion-w The short answer / corollary is that because BPX enforces a strict relationship between active material content and active material volume surface area, when using a BPX JSON file as a parameter input, you are required to set the active material volume surface area in such a way that you get the correct active material content back out. Otherwise the capacity of your cell will be wrong. So you are absolutely correct that the active material volumetric surface area specified in BPX is meaningless in itself. This is hopefully a target issue for the BPX v0.5 release.

@rtimms
Copy link
Contributor

rtimms commented Jul 19, 2024

Yes, let's close this one as it's now linked to the relevant BPX issue.

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

3 participants