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

alternative geometries for lumped thermal models #718

Closed
rtimms opened this issue Nov 8, 2019 · 10 comments · Fixed by #1022
Closed

alternative geometries for lumped thermal models #718

rtimms opened this issue Nov 8, 2019 · 10 comments · Fixed by #1022

Comments

@rtimms
Copy link
Contributor

rtimms commented Nov 8, 2019

At the moment the lumped thermal models assume a pouch cell geometry. We could get users to specify the cell surface area and volume in the parameters file so that the correct ratio can be applied in the Newton cooling. This would be useful if you wanted to do a 1D electrochemical model, with a lumped thermal model for a specific cell geometry.

The Nplus1D thermal models also assume a pouch cell model and will probably remain this way for now as they account for cooling from the face of the current collector (which would be would up in a jelly roll and therefore not open to the air for cooling). It should probably be clearer that these models are for pouch cells only.

@brosaplanella
Copy link
Sponsor Member

If I understand correctly this affects only the cooling area that multiplies the cooling coefficient. If that is the case, should we just let the user specify this area, so there is no need to consider the different cases separately (pouch, prismatic and cylindrical)?

@rtimms
Copy link
Contributor Author

rtimms commented Nov 11, 2019

yeah exactly, my picture was when the user puts in parameters, they explicitly add surface area (but surface area for cooling, as you suggest, is more precise) and volume for that cell. and then in the submodel we use those params so we don't care what the geometry actually was

@brosaplanella
Copy link
Sponsor Member

In fact, unless you need the volume of the cell for some other calculation, you could just pass the surface area for cooling per unit of volume (similar to the specific area defined for the electrode particles). Or maybe that can be confusing for the users?

@rtimms
Copy link
Contributor Author

rtimms commented Nov 11, 2019

yeah i'd be happy with either. might be useful to have volume for other calculations after the fact such as variable x per unit volume.

@brosaplanella
Copy link
Sponsor Member

Makes sense. Then I would define cell volume (which if undefined could be calculated from the electrode thickness and so on) and the cell cooling area so users can play with it.

@brosaplanella
Copy link
Sponsor Member

Following this discussion from a few months ago, it seems that the idea is to pass battery cooling surface area and battery volume as parameters (within the cell parameters, in the macroscale geometry section).

Would it make sense to define that if these two variables are not defined then it assumes a pouch cell? Or is it better to leave it to break and update all the parameter files?

@rtimms
Copy link
Contributor Author

rtimms commented Apr 21, 2020

Maybe we should be explicit in making people define the cooling area and volume. I think the less we assume the better, as people might easily miss assumptions that are hidden away.

@rtimms
Copy link
Contributor Author

rtimms commented May 22, 2020

Not sure what the latest is on this, but my thoughts for how to do this to best fit into the structure would be to pass an option geometry to the lumped model which can, for now, be "arbitrary" (default) or "pouch". Then just put an if statement in the either uses the surface area to volume ratio for cooling param or computes the cooling for the pouch (we could add other popular geometries if we wanted).

Then was choosing the thermal model as an option to the battery model we could do "lumped", "lumped (pouch)", etc.

In the parameters csv we can just put a single value in for the urface area to volume ratio for cooling which we leave people to compute, along with a comment saying what geometry that was computed for.

@brosaplanella
Copy link
Sponsor Member

Sounds good. Do we want to pass as a cell parameter the surface area to volume ratio or pass surface area AND volume?

@rtimms
Copy link
Contributor Author

rtimms commented May 22, 2020

not sure on that. probably pass both as the volume is fixed, but the cooling area can change (e.g. only cooling part of the cell)

brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 26, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
brosaplanella added a commit to brosaplanella/PyBaMM that referenced this issue May 28, 2020
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

Successfully merging a pull request may close this issue.

2 participants