[UNDER-DISCUSSION] OutStreams Inputs

[PaulTalbot-INL]

---

Under Discussion Topic

With the merge of #1329 the OutStream is now an Entity much more like other RAVEN entities, with a base class that is extensible rather than a "manager" that instantiates sub-instances.

This means it should be easier to create custom printing/plotting tasks as OutStreams, such as the dataMining plotting that we already have.

This invites us to consider how we want these to show up in the input file. There's a couple things to consider:

• Can we keep existing inputs for Print and Plot types?
• How clear is the input to a user?
• How consistent is the input with other RAVEN input?
• How well does the input map to the code base?

The existing setup for dataMining uses the structure:

<!-- Method 0, existing -->
<OutStreams>
  <Plot name='existing'>
    <plotSettings>
      <plot>
        <type>dataMining</type>
        ...
<Steps>
  <IOStep>
   ...
   <Output class="OutStream" type="Plot">existing</Output>
   ...

Another option would be to add each new OutStream as a distinct type, keeping Print and Plot as the generic options:

<!-- Method 1, entities -->
<OutStreams>
  <DataMining name='entities'>
  ...
<Steps>
  <IOStep>
   ...
   <Output class="OutStream" type="DataMining">entities</Output>
   ...

Other options may be worth considering, too.

---

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with the under_discussion type?
• 2. If implemented, it will add a new requirement?
• 3. Is a rationale provided? (Such as explaining why the improvement is needed )

---

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

• 1. The discussion determined the addition of a new task issue?

[PaulTalbot-INL]

There's a couple things I like about Method 1 (entities):

• It requires less user knowledge about the internal inheritance structure of the OutStreams. For example, DataMining could inherit from a BasePlot class, without explicitly needing to show it in the input file.
• It's clearer in the Steps (via type) which kind OutStream is being used.
• I can imagine an OutStream that wants to do both plotting and printing, and so shouldn't need to be classified as primarily a plot or a print type; this approach seems to allow that kind of opportunity.

It also allows us to keep the existing Plot and Print the way they are, and is easy to build the InputData for without checking subtypes too much.