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

Introduction of 3 electrode setup #2188

Closed
dion-w opened this issue Jul 24, 2022 · 10 comments · Fixed by #3573
Closed

Introduction of 3 electrode setup #2188

dion-w opened this issue Jul 24, 2022 · 10 comments · Fixed by #3573
Assignees
Labels
difficulty: medium Will take a few days feature priority: low No existing plans to resolve

Comments

@dion-w
Copy link
Contributor

dion-w commented Jul 24, 2022

Description

The feature involves additional potential variables. The first one equates to a potential difference between the current collector of the anode and the middle of separator called "Negative electrode potential vs separator reference". The second one is the potential difference between the middle of the separator and the current collector of the positive electrode called "Positive electrode potential vs sparator reference".

Motivation

Motivation for this comes from the 3-electrode setup in the lab.

In a 2-electrode setup in the lab one can not resolve the individual SOCs of each electrode. You only get the potential difference between both current collectors. In a 3-electrode setup a reference electrode is introduced in the middle of the separator for example a little place of lithium or a whole lithium reference ring around the separator. With the reference electrode, the potentials of both electrodes can be monitored separately. These potentials can for example be used for plating detection on lithium ion graphite anodes.

Modelling this feature directly in PyBaMM is not yet possible. There are already a lot of fancy ways in pybamm to resolve processes on the electrodes directly for example different overpotential contributions. These though can not be compared directly to measured data in the lab. With the mentioned feature there is a way to describe these electrode potentials in PyBaMM and relate them directly to measured potentials in the lab. The additional potential variables could help a great deal for fitting models better to measurements and increase model validity.

Possible Implementation

As a rough draft for my own simulations i implemented the following lines in "base_electrolyte_conductivity". It could be placed in the current-collector submodel or maybe also "base electrode" but since the separator electrolyte potential is needed this would involve including a new submodel at these places. For now these lines worked for me:

        phi_e_s_mid = pybamm.x_average(phi_e_s)  # CAVEAT
        phi_e_s_mid_dim = -param.U_n_ref + phi_e_s_mid * param.potential_scale
        v_n = pybamm.boundary_value(variables["Negative electrode potential [V]"], 'left') \
              - phi_e_s_mid_dim
        v_p = pybamm.boundary_value(variables["Positive electrode potential [V]"], 'right') \
              - phi_e_s_mid_dim
        variables.update(
            {
                "Negative electrode potential vs reference [V]": v_n,
                "Positive electrode potential vs reference [V]": v_p,
            }
        )

There is one caveat though. For a point of reference we need a single value (here termed "phi_e_s_mid"). Typically this would just be the evaluation of the electrolyte in the middle of the separator but until now i did not manage to get it working. I tried to do it with `phi_e_s.evaluate(param.L_n+param.L_s/2)' but it didn't want to be evaluated as it said the method "evaluate is not impleted for "Current function"'. I did not try it with another approach as this wouldn't be working for my system.

Additional context

Provided there is feedback and discussion and it's not too much work to put the feature inside while making sure that everything else in the code still works i would implement this and create a pull request.

@dion-w dion-w added the feature label Jul 24, 2022
@brosaplanella
Copy link
Member

I had a similar issue not that long ago in terms of where are the three electrode potentials defined from. Is it consistent across cells or it depends on the implementation? If the latter, it might be better to leave it to the user to define the variable. Otherwise, the average might be a good approach (as a good approximation).

@valentinsulzer
Copy link
Member

Yeah I agree with Ferran, it all depends how precisely the separator reference is positioned. My guess is it doesn't need to be very precise, since the electrolyte potential doesn't change much over the separator, and so x_average(phi_e_s) is a good approximation. If it is precise, we could implement a new symbol like EvaluateAt(phi_e_s, x_s=...). .evaluate() doesn't (isn't intended to) work on some Symbol types, e.g. Parameter objects that don't have a value.

@dion-w
Copy link
Contributor Author

dion-w commented Jul 26, 2022

Referring to @tinosulzer, this was exactly my orginal idea with EvaluateAt. For now the x_average method only gets the value in the exact middle if and only if the separator electrolyte potential is linear in this region (which it is in the P2D). To make it more robust for other circumstances, future releases and model extensions the symbol EvaluateAt would be helpful since this method would come with no such assumption.
Referring to a possible implementation with EvaluateAt: What do you think if we add another parameter in the "cell"-File (e.g. called "Point of reference potential, normalised distance to negative electrode"). The section in the "cell"-File could be called "Three electrode setup". The parameter would describe the normalised distance from the right boundary of the negative electrode to the left boundary of the right electrode in the separator region? A 0.5 would be right in the middle. This way there could be a stable implementation and the user could even choose where he wants to have his reference potential.

@valentinsulzer
Copy link
Member

Yes, adding that parameter is a good way to do it. Out of interest, how much control is there over the position of the reference electrode in experiments?

@dion-w
Copy link
Contributor Author

dion-w commented Jul 30, 2022

Yes, adding that parameter is a good way to do it. Out of interest, how much control is there over the position of the reference electrode in experiments?

Yeah that's the point what Ferran talked about. I know of two particular experimental setups where you're testing electrodes in the lab in the coin cell format. One is a setup with so called "swagelok-cells" (swagelok coming from the company offering these), and another setup sold commercially is from the company EL-CELL with so called PAT-cells. In both circumstances the reference electrode sits exactly in the middle of the separator. This way a constant offset potential for both electrodes is created and so they are comparable in terms of potential difference. With PAT-Cells there is even a ring electrode around the separator to increase validity of impedance spectra measured with the setup.
So this is for lab scale coin cells. It may be different though if you want to introduce a reference into, let's say, pouch cells but i never worked with these.

So basically: the position of the reference electrode in the electrode is mostly set in stone for experimental coin cell setups and there is actually no need to introduce a movable reference electrode in pybamm. I just mentioned the adjustable distance because of Ferran but maybe i misunderstood him. My suggestion would be to either set it to 0.5 by default, or don't use the additional parameter and just implement it hardcoded to 0.5 in the source code.
but again, while i did some stuff in the lab, i'm using 90 % of my time for simulations, so it might be useful to consider a full time experimentalist for this question.

@dion-w
Copy link
Contributor Author

dion-w commented Aug 2, 2022

Also found a paper nicely explaining the ins and outs of the three electrode setup and what's generally important when dealing with reference electrodes: https://iopscience.iop.org/article/10.1149/2.0231702jes

@valentinsulzer
Copy link
Member

@dion-w are you wanting to get started on implementing this? I can give you some pointers if so

@dion-w
Copy link
Contributor Author

dion-w commented Sep 2, 2022

@tinosulzer You can give them to me. If nothing happened after two weeks i likely had too much to do. But i can try for now as i'm still on vacation.

@valentinsulzer
Copy link
Member

First step will be to implement the EvaluateAt as part of the expression tree. I would recommend doing this in small pieces, one step per PR.

  1. add new EvaluateAt class to UnaryOperators (subclass SpatialOperator), add tests that it works as expected. This should act pretty similarly to BoundaryOperator in terms of how it affects domains, so you can copy that class and tests to get started
  2. implement the finite volumes discretization for EvaluateAt
  3. Add an model option for "three electrode setup", if it's "true" then add the reference potential as a variable in base_electrolyte.py (we don't want to do this if it's "false" so that the parameter for the location of the reference electrode isn't required by default)

@dion-w
Copy link
Contributor Author

dion-w commented Sep 27, 2022

Sorry, i'm busy now and can't say when i would have time for this. You can give it to someone else or just keep it one the list for future use.

@rtimms rtimms added difficulty: medium Will take a few days priority: low No existing plans to resolve labels May 15, 2023
@rtimms rtimms self-assigned this Nov 27, 2023
rtimms added a commit that referenced this issue Nov 28, 2023
rtimms added a commit that referenced this issue Nov 28, 2023
rtimms added a commit that referenced this issue Nov 28, 2023
rtimms added a commit that referenced this issue Nov 29, 2023
rtimms added a commit that referenced this issue Nov 29, 2023
rtimms added a commit that referenced this issue Nov 29, 2023
rtimms added a commit that referenced this issue Nov 29, 2023
rtimms added a commit that referenced this issue Nov 29, 2023
rtimms added a commit that referenced this issue Dec 5, 2023
rtimms added a commit that referenced this issue Dec 5, 2023
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
js1tr3 pushed a commit to js1tr3/PyBaMM that referenced this issue Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty: medium Will take a few days feature priority: low No existing plans to resolve
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants