Is your feature request related to a problem?
Several users / “superusers” (e.g. @g5t) have expressed the wish for “more” Monitor_nD uservars. This is especially interesting for list-mode, since the output is otherwise limited to <=3D.
(The current Monitor_nD implementation stores 1/2D histograms and lists in ascii, 1/2/3D histograms and lists in NeXus.)
Describe the solution you'd like
I propose to enrich Monitor_nD with further uservariables (user0 and user3…user9) which should clearly be “enough” for most cases - and will avoid handling multi-digit uservar names.
I further believe that we should (at least for now) limit these “probeable” vars to double - just like the existing user1…user3.
Describe alternatives you've considered
For the specific idea / need @g5t has mentioned to me, an alternative would be to write another specialised monitor along the lines of the Flex_monitor… type: A uservar-capable, non-propagating monitor.
(In fact, maybe we should just do both.)
Is your feature request related to a problem?
Several users / “superusers” (e.g. @g5t) have expressed the wish for “more”
Monitor_nDuservars. This is especially interesting for list-mode, since the output is otherwise limited to <=3D.(The current Monitor_nD implementation stores 1/2D histograms and lists in ascii, 1/2/3D histograms and lists in
NeXus.)Describe the solution you'd like
I propose to enrich
Monitor_nDwith further uservariables (user0anduser3…user9) which should clearly be “enough” for most cases - and will avoid handling multi-digit uservar names.I further believe that we should (at least for now) limit these “probeable” vars to
double- just like the existinguser1…user3.Describe alternatives you've considered
For the specific idea / need @g5t has mentioned to me, an alternative would be to write another specialised monitor along the lines of the
Flex_monitor…type: Auservar-capable, non-propagating monitor.(In fact, maybe we should just do both.)