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

Let FEProblem return a vector of OutputName based on the output type passed in #2885

Closed
YaqiWang opened this issue Apr 16, 2014 · 1 comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@YaqiWang
Copy link
Contributor

I think this request is reasonable. We can add something like

std::vector<OutputName> FEProblem::getOutputNames<Console>();
or
std::vector<OutputName> FEProblem::getOutputNames(MooseEnum output_type);

so in the actions, I can assign this names to the parameter outputs of a postprocessor.

@aeslaughter
Copy link
Contributor

  • I did implement the ability to return an object by name today:
    OutputBase * = _app.getOutputWarehouse().getOutputByName("my_postprocessor_outputter");
    You will then need to cast this to the correct type, put perhaps we should have a template method that performs the cast automatically.
  • That being said, I think that @YaqiWang's idea is good. However, it would go inside of the OutputWarehouse, so you would call it by:
    _app.getOutputWarehouse().getOutputNames<Console>();
  • I also vote for the first option, we don't want to maintain a list of output class names since the idea is that users can create there own.
  • If users are going to start doing this type of thing, do we need yet another interface: `OutputInterface' that would provide this type of access?

Does anyone else have an opinion on any or all of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Projects
None yet
Development

No branches or pull requests

3 participants