Document output of data objects and solution exports

[joshua-cogliati-inl]

The details of what is written out in when data objects or solution exports are printed should be documented better to make it easier for people to use the results.

---

For Change Control Board: Issue Review

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

• [x] 1. Is it tagged with a type: defect or improvement?
• [x] 2. Is it tagged with a priority: critical, normal or minor?
• [x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• [x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• [x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

---

For Change Control Board: Issue Closure

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

• [ ] 1. If the issue is a defect, is the defect fixed?
• [ ] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• [ ] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
• [ ] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
• [ ] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

[wangcj05]

Metadata from Samplers are mainly used by RAVEN BasicStatisitcs PP, we may need to have a discussion on this if the users want to use this information for their external analysis.

Metadata in Optimizations have been explained in the manual:

Metadata in Postprocessors currently are not explained very well, we need to work on that.

Some suggestions here: Since we dump the metadata information into xml, it may possible to add comments there to explain the meaning of the metadata there.