Skip to content

Thread through the ability to allow grid objects to own memory#144

Open
Yurlungur wants to merge 19 commits into
mainfrom
jmm/unstructured-grid-1d
Open

Thread through the ability to allow grid objects to own memory#144
Yurlungur wants to merge 19 commits into
mainfrom
jmm/unstructured-grid-1d

Conversation

@Yurlungur

@Yurlungur Yurlungur commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator

PR Summary

This MR is on the path to supporting Sesame grids in singularity-eos. In this MR, I extend the spiner infrastructure so that Grid1D objects can own memory. This required extending the serialization routines and getOnDevice and finalize routines to call the appropriate grid objects as well. This ended up being a sufficiently sweeping change/large diff that I decided to split it out into a separate MR to get reviewed/tested by the CI.

One note I want to make that is an engineering decision that I'm not sure I want to keep: Usually we assume all operations in spiner are shallow. However, this "always shallow" model could get cumbersome if multiple databoxes each want to share Grid objects, which might themselves own array data. We have a few solutions to this:

  1. Keep the model and aggressively insist that the user manage memory for Grid objects
  2. Make grid objects use static memory or make them do deep copies

I chose path 1 for now. But I will at least revisit this decision in the subsequent MR when I add non-uniformly spaced grids for real.

PR Checklist

  • Code is formatted. (You can use the format_spiner make target.)
  • Adds a test for any bugs fixed. Adds tests for new features.
  • Document any new features, update documentation for changes made.
  • Make sure the copyright notice on any files you modified is up to date.
  • LANL employees: make sure tests pass both on the github CI and on the Darwin CI
  • If ML was used, make sure to add a disclaimer at the top of a file indicating ML was used to assist in generating the file.
  • If Agentic AI was used, have the AI generate a "proposed changes" markdown file and store it in the plan_histories folder, with a filename the same as the MR number.

If preparing for a new release, in addition please check the following:

  • Update the version in cmake.
  • Maintainers: ensure spackages are up to date:
    • LANL-internal team, update XCAP spackages
    • Current maintainer of upstream spackages, submit MR to spack

@Yurlungur Yurlungur self-assigned this Jul 25, 2026
@Yurlungur Yurlungur added the enhancement New feature or request label Jul 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants