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

Thread UIDs through data_collection #1060

Merged
merged 11 commits into from
Apr 24, 2024
Merged

Thread UIDs through data_collection #1060

merged 11 commits into from
Apr 24, 2024

Conversation

Yurlungur
Copy link
Collaborator

@Yurlungur Yurlungur commented Apr 18, 2024

PR Summary

This PR adds the ability to request a new MeshData or MeshBlockData object by requesting a subset of unique IDs of variables from the parent object, rather than by using only variable names. This should make UID-based operations more usable and thus unlock a bit of performance by minimizing string comparisons. Needed in riot and I suspect also KHARMA.

PR Checklist

  • Code passes cpplint
  • New features are documented.
  • Adds a test for any bugs fixed. Adds tests for new features.
  • Code is formatted
  • Changes are summarized in CHANGELOG.md
  • Change is breaking (API, behavior, ...)
    • Change is additionally added to CHANGELOG.md in the breaking section
    • PR is marked as breaking
    • Short summary API changes at the top of the PR (plus optionally with an automated update/fix script)
  • CI has been triggered on Darwin for performance regression tests.
  • Docs build
  • (@lanl.gov employees) Update copyright on changed files

@Yurlungur Yurlungur enabled auto-merge April 18, 2024 23:04
@Yurlungur Yurlungur added the enhancement New feature or request label Apr 18, 2024
Copy link
Collaborator

@pgrete pgrete left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, looks good to me and nice refactor along the way.
I just don't understand the unit test. Shouldn't 222 != 22 as in hv2(0) != hxv2(0)?
Maybe I'm misreading sth.

Comment on lines 39 to 41
template <typename T>
std::shared_ptr<MeshBlock> MeshData<T>::GetBlock(const int i, const MeshData<T> *src,
const Mesh *pmesh) const {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the GetBlock functionality potentially universal, i.e., applicable beyond the Inititalize call?
I'm asking as GetBlock is a pretty universal name, so if it's special to the Initialize call, I suggest to name it more specific (so that the general GetBlock call remains available for future use).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lroberts36 should jump in here---it's not quite universal, I think... as the MeshData<T> *src piece specifies this as being for Initialize. I will change it to GetSourceBlock_.

Comment on lines 120 to 123
// reset vars
par_for(
loop_pattern_flatrange_tag, "init vars", DevExecSpace(), 0, 0,
KOKKOS_LAMBDA(const int i) { v2(0) = 222; });
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this doing?
Shouldn't this match the xv2(0)=22 call below?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it shouldn't---this inits v2 to the wrong value as a check that it is overwritten when it is called again on line 108 in the new mesh data object, which is not shallow.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't actually write this logic, I copied it from the lines above for the add call by string. I'm fine to remove it if you like.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a comment to this effect.

@Yurlungur
Copy link
Collaborator Author

Thanks for the review @pgrete I think I've addressed your comments now.

Copy link
Collaborator

@lroberts36 lroberts36 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure this works with general partitioning, but maybe I am misunderstanding things. See my comments below.

src/interface/mesh_data.cpp Show resolved Hide resolved
src/interface/data_collection.hpp Outdated Show resolved Hide resolved
src/interface/mesh_data.hpp Outdated Show resolved Hide resolved
src/interface/meshblock_data.hpp Show resolved Hide resolved
@Yurlungur
Copy link
Collaborator Author

@lroberts36 thanks for the review. I think I've addressed all your comments.

Copy link
Collaborator

@lroberts36 lroberts36 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Yurlungur Yurlungur disabled auto-merge April 24, 2024 14:05
@Yurlungur Yurlungur enabled auto-merge April 24, 2024 14:05
@pgrete
Copy link
Collaborator

pgrete commented Apr 24, 2024

With the latest changes the distinction between if (grid.type == GridType::two_level_composite) { and using pmy_mesh_->gmg_block_lists[src->grid.logical_level][i] is gone.
Is that not required any more?

@Yurlungur Yurlungur merged commit dedc15f into develop Apr 24, 2024
49 checks passed
@lroberts36
Copy link
Collaborator

lroberts36 commented Apr 24, 2024

@pgrete: Yeah, that is no longer required since the src MeshData already should point to internal/multigrid blocks.

@Yurlungur Yurlungur mentioned this pull request Apr 25, 2024
12 tasks
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.

5 participants