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

PEP 1 #907

Merged
merged 20 commits into from
Oct 18, 2023
Merged

PEP 1 #907

merged 20 commits into from
Oct 18, 2023

Conversation

bprather
Copy link
Collaborator

This is the minimum viable implementation of PEP 1, #816. Ideally this would include documentation, but I'm really not sure what to write short of an example.

PR Summary

See #816 for a description of why this is cool. tl;dr it takes Parthenon's callback model (e.g., driver calls Update::FillDerived, which then calls any package's registered FillDerived function) and allows user extensions (e.g., driver calls MyPackages::ApplyFloors and that calls a bunch of registered ApplyFloors functions depending on which packages are loaded).

See here for an example extension package type.

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
  • CI has been triggered on Darwin for performance regression tests.
  • Docs build
  • (@lanl.gov employees) Update copyright on changed files

@bprather
Copy link
Collaborator Author

@par-hermes format

Copy link
Collaborator

@Yurlungur Yurlungur left a comment

Choose a reason for hiding this comment

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

This seems pretty minimally invasive, so if it buys you a lot, I'm happy to include it.

Comment on lines 46 to 70
// Returns a sub-Dictionary containing just pointers to packages of type T.
// Dictionary is a *new copy*, and members are bare pointers, not shared_ptr.
template <typename T>
const std::vector<T*> AllPackagesOfType() const {
Dictionary<T*> sub_dict;
for (auto package : packages_) {
if (T *cast_package = dynamic_cast<T*>(package.second.get())) {
sub_dict[package.first] = cast_package;
}
}
return sub_dict;
}

// Returns a list of pointers to packages of type T.
// List contains bare pointers, not shared_ptr objects
template <typename T>
const std::vector<T*> ListPackagesOfType() const {
std::vector<T*> sub_list;
for (auto package : packages_) {
if (T *cast_package = dynamic_cast<T*>(package.second.get())) {
sub_list.append(cast_package);
}
}
return sub_list;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't super object to the new dictionary machinery here, but I wonder if a better approach might be to expose a loop structure. For example:

template <typename T, typename F>
void ForAllPackagesOfType(F &f) const {
  for (auto &[name, pkg] : packages_) {
    if (T *cast_package = dynamic_cast<T*>(pkg.get())) {
      f(name, package);
    }
  }
}

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 considered that, but I think it would be common/useful to add other elements besides just the function call -- e.g. all my loops right now include extra code that can print the function being called, and I can see them as a good point for adding other debugging or common code.

I also sometimes (often) need control of the order that functions are called, e.g. one "floors" function relies on the results of previous. Currently I just hack it by pulling out the package I know needs to be first, then looping over the others. A more general approach might be callback "priorities," but that gets hard to follow reading the code and is more complex to implement so it's not clear we'd want it.

Since only maybe half my callers look anything like that prototype, and I gave up trying to cover the different cases. I'm happy to provide it for other implementations though.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Nah it shouldn't matter much.

src/interface/packages.hpp Outdated Show resolved Hide resolved
@bprather bprather changed the title WIP: PEP 1 PEP 1 Aug 10, 2023
@bprather
Copy link
Collaborator Author

@par-hermes format

@bprather
Copy link
Collaborator Author

I've had to additionally mark some StateDescriptor members protected since I now would like to access them from KHARMA package code. I think all members should be accessible to subclasses, but if there's anything which should still be private I can move it back

@Yurlungur
Copy link
Collaborator

I've had to additionally mark some StateDescriptor members protected since I now would like to access them from KHARMA package code. I think all members should be accessible to subclasses, but if there's anything which should still be private I can move it back

I think that's fine

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.

LGTM

@Yurlungur
Copy link
Collaborator

@bprather looks like the CI is blocking due to a dependency? Is that right?

@bprather
Copy link
Collaborator Author

bprather commented Oct 18, 2023

There aren't unmet dependencies -- it looks like the check itself is broken (cannot find file ...). Could force-merge this and wait for a fix to the check, or remove the check entirely with a new PR. Happy to do either (I think I introduced the check in the first place)

EDIT upstream issue: gregsdennis/dependencies-action#24

@jonahm-LANL
Copy link
Collaborator

jonahm-LANL commented Oct 18, 2023 via email

@bprather
Copy link
Collaborator Author

Looks like it was fixed upstream already! So, I'm gonna hit go on this.

@bprather bprather enabled auto-merge October 18, 2023 21:16
@bprather bprather merged commit ae0632a into develop Oct 18, 2023
49 checks passed
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 this pull request may close these issues.

4 participants