Element groups

[nickmedwards]

1. added --level and --verbose to simdriver\main.cpp. for main, --level changes the file printing behavior. i haven't actually implemented --verbose yet
2. added group to elements to programmatically track groups of elements. i tried to make this backwards compatible, so simulations without groups wouldn't need to be changed. currently groups must be added through the JSON file. elements are given a group by the "group" key. groups must be non-negative integers.
3. default group for single elements is -1 (ie ungrouped) set in single_element.cpp, composite/stage/etc elements are given -2 because they don't interact with the trace
4. created struct SolTrace::Result::GroupResult to hold the counts for a given group. right now it just has basic counts (ie absorbs/reflects), but i will write a function for comparing GroupResult structs to get stuff like efficiencies.
5. added a vector of GroupResults to SimulationResult and created SimulationResult::write_group_json_file to write those structs to a json file
6. i think that it would be potentially useful to used group information in the trace itself, so i added the groups to OptixRunner. haven't added groups to the other runners, yet.
7. added enum SolTrace::Runner::RunnerStatistics to toggle between different reporting behavior, ie does runner.report_simulation(&result, level) return the ray record data, the group results, or both?
8. created some tests to cover my bases, all are in \unit-tests, added some json files for testing file io behavior

[jmaack24]

I like this feature. I think forcing a group to be an interval of element ids is too rigid though. It would make grouping difficult to use in a python script and nearly impossible to use with the GUI.

There is also no implementation done for the NativeRunner or EmbreeRunner. At a minimum, there should be some sort of error printed or thrown for those two runners that say this feature has not been implemented. From the user survey results, I expect these are going to be the most commonly used runners by users.

[jmaack24]

This should live in OptixRunner rather than here. See comment on line 109 of soltrace_system.h

Again, I think we need a grouping implementation that is more flexible.

[nickmedwards]

Moved to OptixRunner here. Let me know if I should add to other Runner's now too. I left it at the OptixRunner for now because that's what I'm using for the annual study.

[taylorbrown75]

Should we change the JSON schema with this pull request? That process is not defined, but it seems like adding json variables would be a good time to increment it. @jmaack24

[jmaack24]

Should we change the JSON schema with this pull request? That process is not defined, but it seems like adding json variables would be a good time to increment it. @jmaack24

We probably should come up with a process for changing the JSON schema or some sort of versioning for it. What were you thinking of adding?

[taylorbrown75]

Should we change the JSON schema with this pull request? That process is not defined, but it seems like adding json variables would be a good time to increment it. @jmaack24

We probably should come up with a process for changing the JSON schema or some sort of versioning for it. What were you thinking of adding?

I don't have a plan in mind. I'll add a note so we remember to discuss it at the next meeting.

[nickmedwards]

@taylorbrown75 Here is what I got going for friend access for a test. I didn't want to use the FRIEND_TEST marco because it involved changing the CMakeLists.txt to build non-test builds with gtest, and I didn't want to get into all that.