Add Analysis design doc

[brian-oneill]

Add Analysis module design document. Compiled here.

Describes the configurable operator framework for in-situ analysis computation, including:

• Templated operators with type-safe runtime dispatch
• Operator factory and registration system
• Compute scheduling driven by dependency-based alarms
• Bundled analysis groups integrated with IOStream output
• Future fully composable operator chains (target design)

Checklist

• Documentation:
  • Design document has been generated and added to the docs
  • Documentation has been built locally and changes look as expected

[cbegeman]

For my understanding, why is it important to support both device and host locations? Is it that the actual operations would be conducted on the device but we would accept inputs that originate on the host and are copied to device within the operator?

[brian-oneill]

Actually, after thinking it over, I'm leaning towards not supporting HostArray types. Given that the compute work is currently done almost exclusively with ArrayDDTT types (ArrayMemLoc::Device arrays for GPU builds and ArrayMemLoc::Both for CPU-only builds), supporting HostArrayDDTT (ArrayMemLoc::Host) seems unnecessary right now, especially given deadlines.

Adding HostArray support to the analysis code would significantly increase code bloat and complexity. This would require either:

• memory transfers (as you mention). This would also complicate the operator templating, since output arrays could no longer be straightforwardly templated off the input arrays
• branching compute methods. Each operator compute method would require if-else branches, with duplicate code for kokkos kernels or ordinary loops depending on ArrayMemLoc.

If a compelling need comes up later, we can add this support then. The analysis module will continue to evolve after the immediate delivery, so I think we can avoid adding in this extra complexity prematurely.

[cbegeman]

Sounds good. I support this simpler path.