How would we want a replacement chopper component to look / behave?

[willend]

Picking up on #2347 my own 0.02€ are:

• We should implement a DiskChopper that behaves "as expected" (i.e. starting from what Scipp have written up and/or NeXus define?)
• The component should make use of the vector type input to add multiple openings pr. disc
• The component could potentially allow for transmission (e.g. using material-strings from NCrystal)
• Related documentation should be crystal clear
• Once such a replacement-component exists we should
  1. Make test-instruments that illustrate the differences to the legacy chopper comps
  2. Adapt (at least most) of the example instruments to the new component definition
  3. Put the two older comps in obsolete

[mads-bertelsen]

Great initiative!

Agree on the above, only a little uncertain about the best interface for adding multiple openings. Going from GROUP to handling them in the standard component would be great. Vector input is great for hardcoded values, but using parameters or variables requires a bit of DECLARE / INITIALIZE code. That is probably okay for the definitions of openings, typically frequency and phase will use parameters/variables and these do not need to be vectors.

The other slight issue with vector input is that there size cannot be read, so another variable is needed to convey that. The MultiDiskChopper has a default value of length 2, but perhaps it should be a required parameter. Is there any potential way to improve this aspect?

I propose simply calling the new component Chopper, as a disc chopper seems to be by far the most common type of chopper. I intend to start a prototype soon and make a branch that would provide something concrete for this discussion.