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

Cleaning up geometries and meshes #1029

Closed
valentinsulzer opened this issue May 28, 2020 · 2 comments · Fixed by #1032
Closed

Cleaning up geometries and meshes #1029

valentinsulzer opened this issue May 28, 2020 · 2 comments · Fixed by #1032
Assignees

Comments

@valentinsulzer
Copy link
Member

The geometry and meshes are quite messy and hard to understand right now. Some ideas for cleaning them up:

  • Get rid of lists of submeshes. I think this originally had two purposes:
  1. Allow varying submeshes (e.g. 10 r-grid points at x=0, 20 r-grid points at x=0.1, etc). I don't think we need to support this behaviour going forward. We can just say that we only support nice regular geometries. And a lot of the spatial methods just assume that everything behaves like submesh[0] anyway.
  2. Record how many submeshes there are. We should be able to read this from auxiliary_domains instead.
  3. Any other reasons @Scottmar93 @rtimms ?
  • Clean up geometries to get rid of "primary", "secondary", etc. Again, if we use auxiliary_domains more, we don't need to distinguish between the geometries so much. The only distinction required will be 0-1-2D current collectors. So the messy Geometry class can just be replaced by a single function
def battery_geometry(current_collector_dimension):

This will be challenging to implement but should be doable. But it's possible that I'm missing something and this will be fundamentally too difficult.

@rtimms
Copy link
Contributor

rtimms commented May 29, 2020

Think this sounds great and I can't think of any reasons not to do it off the top of my head. I think the only time the submesh list is used is to get its length and as you say we should be able to get this from auxiliary domains.

The keys "primary" etc. are used in meshes to calculate the total number of points and so on. Will the new framework include auxiliary domains as part of the geometry (at the moment auxiliary domains is a feature of a symbol)? We'll still need some way of getting the right number of repeats. I guess this is what you are getting at in your second bullet

@valentinsulzer
Copy link
Member Author

Yeah, the discretisation would have to read self.mesh[auxiliary_domains["secondary"][0]] to find the number of repeats. But it's starting to have to do this anyway, for example for #632 we end up with some variables where primary domain is "negative particle" and secondary domain is "current collector", but the number of mesh repeats assumes that secondary domain is "negative electrode", so you get size errors.

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