Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with cuts for different "Intensity" types (mainly GDOS) #923

Open
mducle opened this issue Jul 5, 2023 · 1 comment
Open

Issues with cuts for different "Intensity" types (mainly GDOS) #923

mducle opened this issue Jul 5, 2023 · 1 comment
Assignees

Comments

@mducle
Copy link
Member

mducle commented Jul 5, 2023

Describe the bug

The ability to make 1D cuts with different types of intensity was recently added to MSlice, but there are a couple of usability issues encountered during recent user experiments.

  1. To compute GDOS type cuts, MSlice must know the sample temperature for a run. It is meant to ask the user for this the first they make a slice or cut with GDOS or Chi'', and then to cache this value. This works for slices, but not for cuts (the user is asked for the temperature each time the plot a cut from a workspace.
  2. Using the "Cut" tab, the intensity always defaults back to "S(q,w)" even when using the same plot window (e.g. it is in the "Make Current" state) - e.g. if users want to replot the same workspace with a GDOS cut but with different binning, they have to click "Plot" then go to the plot window, select "Intensity" and then "GDOS" and then type in the temperature. It would be a lot easier if MSlice "remembers" the cut type of the plot window.

Both these issues make using the different intensity options for "Cut" quite user-unfriendly.

To Reproduce
Steps to reproduce the behavior:

  1. Load a dataset and go to the "Cut" tab. Put in any values for the cut parameters and press "Plot".
  2. In the plot window, click "Intensity" then "GDOS" and then type in a number (e.g. 10) for the sample temperature; check that it plots the GDOS.
  3. Go back to the main window and the "Cut" tab. Click "Plot" again (also maybe change the bin size or integration range) - see that the plot window reverts back to "S(q,w)".
  4. Click "Intensity" in the menu of the plot window and then click "GDOS" - see that it asks for the temperature again.

Expected behavior

The temperature should be cached for each workspace so that users don't have to enter it each time they make a cut (this is a true bug).

The plot window should "remember" the types of intensity used in a previous cut and to plot the same type of intensity if users replot on the same window (this is a usability issue; the intensity type feature is new for cuts so there was no previously defined behaviour).

As an alternative the type of cut could be specifiable as a dropdown menu in the "Cut" tab of the main window and this setting "remembered" for each workspace like with the other settings for "Cut". This would mean that the plot window would not need to know about previous cut intensity types.

MSlice 2.6.0 used in Mantid 6.7.0

@mducle mducle added the bug label Jul 5, 2023
@MialLewis MialLewis added enhancement and removed bug labels Sep 15, 2023
@MialLewis
Copy link
Contributor

I've changed this to an enhancement, as it's "working as intended" from my perspective when I added the feature. Now I understand the use case better, we can look to make these improvements.

At the moment, temperature is cached on a slice once created. This temperature is propagated to any cuts that are derived from this slice. If you close the slice, and plot the same slice again, you will once again be prompted to for a temperature, in contradiction to point 1 above.

It sounds like it makes sense to cache temperature directly on the mslice workspace that wraps around the loaded raw workspace? That way, any temperature set for a cut/slice will be applicable to all derived from that workspace.

@SilkeSchomann SilkeSchomann self-assigned this Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants