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

Ensure MeshCoord points and bounds always agree with the Mesh (while keeping Mesh mutable) #4757

Open
stephenworsley opened this issue May 19, 2022 · 2 comments · May be fixed by #6125
Open
Assignees

Comments

@stephenworsley
Copy link
Contributor

stephenworsley commented May 19, 2022

📰 Custom Issue

See also #4749 for a simpler fix and a description of the problem.

Currently, both the MeshCoord points and bounds and the data on the mesh they refer to are all mutable. In the case where the Mesh has already been realised before the MeshCoord has been created, the points will have the same underlying array as the Mesh data so changing one will change the other, however this is not true in all other cases. Furthermore, when the Mesh is lazy, all MeshCoords that derive from it will instantiate their own points and bounds so that if all derived MeshCoords are realised, the same data will exist in different copies, taking up more memory than may be necessary.

A possible suggestion to improve matters:

  • Make points and bounds on MeshCoords read only properties.
  • Have the points and bounds properties fetch data from the Mesh object. This may involve storing a private _mesh_bounds array on the Mesh when called for.

This approach would improve the memory performance when referencing the same Mesh multiple times and, unlike the solution proposed in #4749, may also allow the safe editing of the Mesh.

@stephenworsley stephenworsley changed the title Ensure MeshCoord points and bounds always agree with the Mesh Ensure MeshCoord points and bounds always agree with the Mesh (while keeping Mesh mutable) May 19, 2022
@github-actions
Copy link
Contributor

In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity.

If this issue is still important to you, then please comment on this issue and the stale label will be removed.

Otherwise this issue will be automatically closed in 28 days time.

@github-actions github-actions bot added the Stale A stale issue/pull-request label Oct 29, 2023
Copy link
Contributor

This stale issue has been automatically closed due to a lack of community activity.

If you still care about this issue, then please either:

  • Re-open this issue, if you have sufficient permissions, or
  • Add a comment stating that this is still relevant and someone will re-open it on your behalf.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 26, 2023
@bjlittle bjlittle added Feature: UGRID and removed Stale A stale issue/pull-request labels Nov 29, 2023
@bjlittle bjlittle reopened this Nov 29, 2023
@scitools-ci scitools-ci bot removed this from 🚴 Peloton Dec 15, 2023
@trexfeathers trexfeathers linked a pull request Aug 20, 2024 that will close this issue
@trexfeathers trexfeathers removed their assignment Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

4 participants