-
Notifications
You must be signed in to change notification settings - Fork 44
Add support for "user" output #1362
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
base: develop
Are you sure you want to change the base?
Changes from all commits
f84dd6a
adb186a
fbc7fa2
df6a471
7f00e54
bdb997a
64315c5
5bd6c97
2f47ad5
f12e966
7472dfe
bdc2b9a
6cd9e8d
372456d
37b7068
f11f016
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| //======================================================================================== | ||
| // Parthenon performance portable AMR framework | ||
| // Copyright(C) 2020-2026 The Parthenon collaboration | ||
| // Licensed under the 3-clause BSD License, see LICENSE file for details | ||
| //======================================================================================== | ||
| // (C) (or copyright) 2020-2024. Triad National Security, LLC. All rights reserved. | ||
| // | ||
| // This program was produced under U.S. Government contract 89233218CNA000001 for Los | ||
|
|
@@ -22,6 +26,7 @@ | |
| #include "basic_types.hpp" | ||
| #include "bvals/boundary_conditions.hpp" | ||
| #include "defs.hpp" | ||
| #include "interface/outputs.hpp" | ||
| #include "parthenon_arrays.hpp" | ||
|
|
||
| namespace parthenon { | ||
|
|
@@ -93,9 +98,16 @@ class ApplicationInput { | |
| BValFunc GetBoundaryCondition(BoundaryFace face, const std::string &name) const; | ||
| SBValFunc GetSwarmBoundaryCondition(BoundaryFace face, const std::string &name) const; | ||
|
|
||
| // Custom user outputs | ||
| void RegisterUserOutput(const std::string &name, | ||
| std::shared_ptr<OutputType> output_type); | ||
| std::shared_ptr<OutputType> GetUserOutput(const std::string &name); | ||
|
|
||
| private: | ||
| Dictionary<BValFunc> boundary_conditions_[BOUNDARY_NFACES]; | ||
| Dictionary<SBValFunc> swarm_boundary_conditions_[BOUNDARY_NFACES]; | ||
|
|
||
| Dictionary<std::shared_ptr<OutputType>> user_outputs_; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could this be a dictionary of factories rather than storing Dictionary<std::function<std::shared_ptr<OutputType>(OutputParameters)>> user_output_factories_;This way the user outputs could be generated newly for each input block. I think of use cases like the multiple history files generated in the advection example
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought about the factory and the decided for the full derived class approach because I thought it's more flexible, e.g., when a user want to keep some state between outputs (e.g., thinking about some ADIOS2 streaming based output). Similarly, with the current approach multiple output of the same type are still possible, aren't they? As far as I can tell, should work out of the box as
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In your example when you call
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, yes, good point.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the factory would be clearer downstream, but cloning should get the same resulting behavior.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just to double check: Do you imagine the factory living in Parthenon with the downstream code just providing shared ptr to the
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was thinking it would be something like pman.app_input->RegisterUserOutput(
"particle_user_output",
[](OutputParameter op){
return std::make_shared<particles_leapfrog::ParticleUserOutput>(op);
}
);, which I don't think would preclude allowing the downstream code to own the object, since the factory doesn't have to always make a new object. You could even throw from the factory function if the output type gets used in multiple input blocks |
||
| }; | ||
|
|
||
| } // namespace parthenon | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.