Unable to Aggregate on "Groups of Components"

[Michael O'Keefe]

Problem

Templates allow users of ERIN to define concepts that involve multiple components (and potentially multiple systems of systems of components!). However, the current output reporting does not have any concept of the original template system. Ideally, we would want to be able to (optionally) aggregate results at the level of the original template components.

Proposed Solution

Adding an optional "group" field to the TOML input file allows for aggregation at the "group" level. For aggregation at the group level, we just need to track when flows:

• go into a group from outside
• go out of a group from inside
• flow to waste (should be auto-tracked)

Additionally, we'll want to aggregate all storage within a group by flow to present as one single store per flow.

In order to facilitate this, we may want to create one or more of the following data structures:

std::unordered_map<string, std::set<string>> { Group Name => Set of Component Names }
std::unordered_map<string, string> { Component Name => Group Name }

When writing the output files, we would elide writing any component names that are part of a group and instead aggregate on the group level. There may be a way to pre-process all results prior to them being sent to the output writing and statistics aggregation routines -- this would be ideal.

TODO ITEMS:

• add an optional parameter to the input structure called group that takes a user-defined string
• when groups are specified, aggregate the output according to their group instead of their individual component
• enable a flag on the run command called --no-group which means to not aggregate by group. The default is --group which means groups are "on". The purpose of the switch would be for debugging so as to see the original component values prior to group aggregation.

REFERENCES

• see erin_next_validation.cpp and erin_next_validation.h and the FieldInfo fields to set the "group" field on all components
• see erin_next_simulation.cpp: WriteEventFileHeader, WriteResultsToEventFile, WriteStatisticsToFile
  • ideally, we could "repackage" the input to these files by their groups to allow them to continue to work as-is

QUESTIONS

How should failure modes and fragility modes apply to groups?

(Tentative answer) I think that any fragility mode that applies to any component within a group applies to the entire group. That is, any "non-available" status will cause the entire group to toggle to a non-available status. Multiple (different) failure modes/ fragility modes applicable to different components will collect on the entire group.