Requirements

This page is where requirements can be collected, structured and discussed (at least preliminarily).

Unstructured requirements / Brainstorming / WIP

Supporting "deactivation" of "non-self-continuous" subchains

Use case description

ESR operators were used to creating a complete supercycle first, then deactivating all kinds of machines at will. Users had to be careful when deactivating machines that were "non-self-continuous" (machines containing function settings for which the first value at the start of the machine differs from the last value at the end of the machine), as deactivating the wrong machine could easily cause beam loss. The Reset machine could handle deactivated non-self-continuous machines, it always brought the devices to the expected injection level from wherever they were ( AW: Correct??)

This line of action was used to be able to easily switch from e.g. "only injection" to "only injection and one deceleration" to "only injection and two decelerations", etc., and vice versa

During the CCT meeting in which the Storage Ring mode concept was presented (2018-11-29), statements by M. Steck and S. Litvinov confirmed that they would like to do something similar again in the future.

AW: I need to clarify if this is really how the old system was used, and why it was used that way. Also clarify if this is an requirement for regular operation or for commissioning.

Capabilities of the Storage Ring mode concept

In the current Storage Ring mode concept, there will be "skippable" subchains that can be easily activated/deactivated using specific signals. However, only "self-continuous" subchains (a subchain that is, citation following, " "continuous" with itself in the sense that for function settings, the first value (beginning of the function) in the first Beam Process has to be same as the last value (end of the function) in the last Beam Process" (Storage Ring mode concept -> Skipping), can be skippable.

Therefore, the "skippable subchains" feature is not suitable for the use case of "skipping" non-self-continuous subchains.

Possible Approaches

There are multiple possible approaches. Here is some brainstorming. Please note that the Pros and Cons are not weighted in any way: a large number of Pros for one approach does not mean that approach is necessarily better than another approach with a smaller number of Pro, etc.

"Deactivating" by trimming into flat functions with length ~0

Assuming that the length of the subchain is the result of a ramping function that takes a certain amount of time to go from one level to another level, the function could be trimmed to be constant (start and end the same, no change inbetween). The length would then be acceptably close to 0.

Pros

• Deactivating works "out of the box" (for (re-)activation see below)
• Adaptation of other subchains is handled automatically by LSA via propagation
• Time span for Activating/Deactivating is described by the time a trim (+ drive) takes
• No switching of resident contexts (might be helpful for other applications that work with the resident context)

Cons

• The subchains are not truly deactivated: They are still played, they are just very very short and do not do anything interesting.
  • This might be confusing for the users (he might still see events for their beam processes, and technically a marker for showing which subchain is currently being played could show a "deactivated" subchain being played.
    • This might not be problematic depending on how the "deactivation" of those subchains is communicated: They are not "skipped", but rather "made effectless".
• Re-Activation needs extra work: The user wants to switch back to the previous settings, but how?
  • The application could "remember" the previous settings, but that seems error-prone and very complex (what happens if the application is closed/opened elsewhere -> persistence, etc.)
  • The application could re-trim the settings of the subchains from before the "deactivation" trim (= the application would have to be able to identify the associated deactivation trim - how??). This would not necessarily lead to the exact same result settings as before, e.g. because MakeRules were changed etc. Maybe that would be acceptable?
    • Checked with Raphael if that sounds feasible: It might work, as long as only ramp endpoints are trimmed. Trimming all the settings of the "deactivated" subchain would not be good, we might overwrite settings (e.g. the ramp start) that were changed by incorporation from earlier in the pattern. Raphael thinks this approach seems kind of brittle/too much work in the application.
    • AW: Check with Sergey if that might be acceptable. (?)
    • AW: If the application was closed while a subchain is "deactivated" like this, how would a new instance of the application detect the "deactivated" state? By checking the trim history for a "deactivation trim"?

Notes

• An idea by Raphael: Assuming we had a setting "ramp_start_value" and a setting "ramp_end_value", the model could support a "make_flat" boolean setting that, when true, computes the ramp by treating the start value as the end value, simply ignoring the real end value. Switching between the flattened, short ramp and the real ramp would then be simple by trimming the value of the "make_flat" setting.

No "deactivating" of subchains, instead working with multiple related patterns

Instead of trying to "skip" or "deactivate" the subchains of a pattern, the users should work with multiple patterns that contain only a subset of the subchains belonging to the "full" pattern. This

Pros

• Avoids workarounds to emulate the "skipping" or "deactivating" of subchains, instead "WYSIWYG" - only the subchains that belong to each pattern can be played.

Cons

• In order to be practical for usage, we will have to come up with a mechanism for keeping the settings in the various patterns in sync: Trims on one pattern should, in the end, affect all the other "related" patterns.
  • How can the application identify which patterns are related, i.e. what is the "full" pattern and which patterns are "partial" patterns for that full pattern?
  • Would the user have to explicitly create the partial patterns for all subchain combinations he might want to use later? When? Can he add forgotten partial patterns later? Or could the application create partial patterns on the fly, always using the full pattern as a base?
  • How are settings/trim applied to one of the related patterns transferred to the other related patterns?
    • The user could use the export/import mechanism of ParamModi, but this would be very tedious for them and probably very error-prone (can easily be forgotten).
    • The application could use the export/import mechanism of ParamModi. (When (after every trim or only when patterns are switched)? Between which patterns?)
    • The application could use a copy settings trim. (When (after every trim or only when patterns are switched)? Between which patterns?)
    • What happens to trims to one of the related patterns that is not the "current" pattern? Will they be silently overwritten on the next pattern switch/the next transferral trim?
  • What happens if settings transferral from one pattern to another fails?
  • Are multiple patterns problematic for the trim history? Would multiple small trims on one pattern be squashed into a big transferral trim on a pattern switch, or would we have to perform multiple almost identical trims (one for each related context)? (Again: What if settings transferral fails in one or more case?)
• Probably slow?
  • Very likely slow if we have to actually switch resident patterns:
    • [If necessary: Decouple Pattern A]
    • Make Pattern A non-executable
    • [Possibly: transfer (trim) settings from Pattern A to Pattern B]
    • Make Pattern B executable (includes drive)
    • [If necessary: Couple Pattern B]
  • Probably not quite as slow if we have multiple resident patterns ready in the Storage Ring pattern group - then we could switch fast by simply enabling/disabling patterns "by OP". However, we have limited space in our timing master cores. At Sis18, the limit is 4 patterns.
    • AW: Check with Raphael/Andreas: Are there any estimations whether there could be multiple resident ESR patterns? If so, how many?
    • If the user wants to switch between more patterns than can be made resident, switching is still slow (see above).
• Probably needs a good concept for making the switch seem easy to the user, without hiding relevant information (e.g. which pattern is currently resident)
• Might be problematic for other applications - if they work on the currently resident pattern, they will have to switch (which might be easy or complicated, and might lead to outdated contexts unless we have notifications)

Notes

• AW 2019-02-06: Raphael stated that he asked David about this use case. If I understood Raphael correctly, David questioned whether deactivating non-self-continuous machines ever actually "worked" in the old system. He would like to know more about the actual requirements (what was it used for, why was it used like that -> what were they trying to achieve). He also suggested that ESR operators should either use the "multiple pattern" approach and synchronize settings by hand using the ParamModi import/export feature, or that they should use the "trim into flat functions" approach and keep track of the desired ramp values themselves (e.g. ramp is 50 -> 100. User trims 50 -> 50: Ramp is flat and short, effectively "deactivated". When the user wants to re-activate the ramp, she should trim 50 -> 100 (or whatever value the ramp should now go to).). There would be no application support for "remembering" the previous ramp end value, at least not in the initial stage.

Abort measure operation / skip once / skip to deactivate

The new system supports skipping certain subchains. There is certainly the requirement to end a measure operation preliminary. In this case on the currently running measure subchain is aborted, it has no impact on the next cycle. At least in the old system ESR operators could (de-)activate a machine permanently. Stakeholders have expressed that is still a valid requirement. Do we need a feature that skips subchains temporarily?

What is the desired manipulation subchain when changing settings?

Q: In the new system users can not just start one manipulation session at the end of the cycle but freely define a few manipulation subchains anywhere in the chain. So when users prepared a manipulation in ESR Modi the cycle was set to 'stop at the end and manipulate' when pressing the 'Setzen' button. When this workflow is transferred to the new system the question arises if operators want to trim the next manipulation subchain in the cycle or if the want to address a certain manipulation subchain.

A: ???

-- AnnekeWalter - 04 Feb 2019