Interface for single- vs. multi-partition running

[elaird]

A question: could selecting the LPM FM be equivalent to choosing single- vs. multi-partition running? I am not aware of any reason to control an LPM for single-partition running. Nor would it be possible to take multi-partition runs without the LPM.

If so, it would naively seem to open up the possibility of simplifying drastically the FMselection/masking GUI.

[jhakala]

The GUI's masking interfaces are based around masking function managers -- the two panels could more appropriately be called the "multi FM" and "single FM" selections. (You are right--it doesn't make sense to pick the LPM FM in the single FM mode, but masking the LPM FM in multipartition mode does have at least one use case: to configure multiple HCAL FMs without trying to configure TCDS, which can be useful if one is doing tests while TCDS is unavailable.) As it is now, the GUI is totally agnostic about the details of which FMs are doing what, and there is nothing special about the TCDSLPM FM as far as the GUI knows.

The reason for this design (that the GUI doesn't get too involved in the details of what FM is doing what) is basically motivated by the fact that the HCALFM is meant to support not only the TCDS systems (P5 and 904) but also non-TCDS systems (H2, B28, cmshcal14, FNAL, etc.) We have built in some logic to do some simple switching for single and multipartition modes, but these features are added purely "on top" in the sense that they add the handling of single partition and multipartition ICI/PI configurations when TCDS is in play, but when TCDS is not in the picture, these switches have no effect, and moreover, they cause no new work/headaches for the maintainers of non-TCDS systems.

So the GUI features you request would first require some additional logic in the server side to let the GUI know whether we're using a TCDS system or not. Then, once such a flag is present, we could consider adding a new TCDS-specific interface with the behaviors you request, but I'm not sure building up that kind of elaborate logic, especially logic that resides in the GUI code, would be maintainable in the long term unless we get another person to work on GUI development.

[elaird]

It does seem critical to support non-TCDS setups and quite desirable not to code elaborate details into the GUI.

How about eliminating the "single-vs-multi" toggle, and choosing the appropriate mode automatically based on the total number of FMs?

[jhakala]

This should probably wait until after we have the localDAQFM -- for typical local runs, we'll always want the localDAQFM in, so we should see how that gets implemented before introducing logic that relies on the arithmetic of the number of FMs.