Ticket #8937 (closed: fixed)
Design CLI for plotting
Reported by: | Owen Arnold | Owned by: | Owen Arnold |
---|---|---|---|
Priority: | critical | Milestone: | Release 3.3 |
Component: | Framework | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | #8912 | Tester: | Federico M Pouzols |
Description
Output will be a design document approved by scientists and developers from both facilities. This will be the default flavour of plotting interface (not Horace).
Estimate 1-2 weeks
Change History
comment:3 Changed 6 years ago by Owen Arnold
The basic agreement is to make the plotting as matplotlib like as possible.
comment:4 Changed 6 years ago by Owen Arnold
The basic design document has been read and agreed to by the member of the technical steering committee at bot the SNS and ISIS. https://github.com/mantidproject/documents/blob/master/Design/Plotting/plotting_cli.md
comment:5 Changed 6 years ago by Owen Arnold
- Status changed from assigned to verify
- Resolution set to fixed
Federico and I are now working on implementing this.
comment:6 Changed 6 years ago by Federico M Pouzols
- Status changed from verify to verifying
- Tester set to Federico M Pouzols
comment:7 follow-up: ↓ 8 Changed 6 years ago by Federico M Pouzols
- Status changed from verifying to closed
I've had a look at the relevant docs, and the other day Owen explained to me what's the aim and approach here. So I think I can make a neutral evaluation, as I haven't been involved in this so far. On the other hand I'm not very experienced with Mantid, so take these comments with tons of salt. To sum up in a couple of points:
- The detailed objectives seem sensible and clearly defined to me. I just note a possible question mark, when they say "Additional top-level plot command that will inspect the data and plot it in the most sensible form", the "most sensible form" for so many different kinds of things may have different meanings for different users. This may require careful thinking/feedback/testing.
- Longer term, we'll need to explore how much of Matplotlib we can/want to support. And in the opposite direction, we'll need to explore how to wrap the tools and plotting functionality of Mantid that are definitely not Matplotlib-like to make them look as Matplotlib-like as possible.
Good points to note:
- There are a few examples in the design document and even some code in the mantid repository which give a good idea of what would be the concrete direction to take.
- The approach taken maintains full backwards compatibility, which would be my main concern, by providing the new functionality in a 'future' package. This is also great for testing/getting feedback.
comment:8 in reply to: ↑ 7 Changed 6 years ago by Owen Arnold
Very good questions!
Please remind me about this at some point soon, as we should expand this document to include answers to your questions.
Replying to Federico M Pouzols:
I've had a look at the relevant docs, and the other day Owen explained to me what's the aim and approach here. So I think I can make a neutral evaluation, as I haven't been involved in this so far. On the other hand I'm not very experienced with Mantid, so take these comments with tons of salt. To sum up in a couple of points:
- The detailed objectives seem sensible and clearly defined to me. I just note a possible question mark, when they say "Additional top-level plot command that will inspect the data and plot it in the most sensible form", the "most sensible form" for so many different kinds of things may have different meanings for different users. This may require careful thinking/feedback/testing.
- Longer term, we'll need to explore how much of Matplotlib we can/want to support. And in the opposite direction, we'll need to explore how to wrap the tools and plotting functionality of Mantid that are definitely not Matplotlib-like to make them look as Matplotlib-like as possible.
Good points to note:
- There are a few examples in the design document and even some code in the mantid repository which give a good idea of what would be the concrete direction to take.
- The approach taken maintains full backwards compatibility, which would be my main concern, by providing the new functionality in a 'future' package. This is also great for testing/getting feedback.
Bulk move of tickets out of triage (new) to assigned at the introduction of the triage state