Broken workflows when using `with_sample_runs` and `with_background_runs`

[SimonHeybrock]

I think I introduced a bug in #163. After that change, the nodes we should "reduce" at in the graph are different. I did not look into all details yet, but very roughly:

• Sum CleanMonitor.
• We should not sum or concat CleanSummedQ[Denominator], I think? Should this be the mean now? In general this should be the same in all runs, so we might also check for that, or not even to any map/merge in this branch?
• Is this still consistent overall? Is it ok to split the CleanSummedQ[Denominator] from the monitor sums, which affects the transmission fraction? It makes sense when a separate transmission run is used, but does the logic carry over to the case of using the transmission monitors from the sample runs? What about cases where the solid angle term is different (rear detector moved), shouldn't we add the monitor contribution before reducing the denominator term?

[SimonHeybrock]

It might be as simple as changing to reducing everything at WavelengthScaledQ (or ReducedQ) instead?

But this poses the question why the implementation prior to #163 computed the transmission fraction as it does, on a per-run basis. Wouldn't there be less noise (when using transmission from sample run) if we summed each monitor before computing TransmissionFraction?

[nvaytet]

Wouldn't there be less noise (when using transmission from sample run) if we summed each monitor before computing TransmissionFraction?

Do I remember correctly that with_sample_runs and with_detector_runs is used to map over runs that had the same params, meaning that the event lists can just be combined?
If that is so, then I think it should indeed be better to combine for transmission run.

If we were combining the event lists very early in the workflow, we would just get this automatically. But I think we didn't want to do that because the data would get very large in memory?