Skip to content

DOC: start to document project goals and scope#6

Open
tacaswell wants to merge 4 commits intoNSLS-II:masterfrom
tacaswell:doc_manifesto
Open

DOC: start to document project goals and scope#6
tacaswell wants to merge 4 commits intoNSLS-II:masterfrom
tacaswell:doc_manifesto

Conversation

@tacaswell
Copy link
Copy Markdown
Member

No description provided.

Comment thread README.rst
Other dependencies (databroker, xarray, scikit-beam, scipy, etc) may
be injected into widgets.

- widgets that take in structured meta-data should take in documents
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only thing I'm slightly unsure about. No problem with "data" being entered in the event model, but does this include the setup of other widgets. For instance, using the spinbox with label example, it would be nice if this could be setup with a dictionary of configuration information about a Signal but are we going to enforce that this is a describe document?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also a bit skeptical to enforce the event model.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I think this is data/meta-data meaning getting crosswise. I agree with @teddyrendahl that we do not need full document model from configuration-of-widgets dictionaries!

I was thinking more of "I am a widget that takes an x-y pair and then plots a time-trace of them" or https://github.com/lbl-camera/Xi-cam.gui/pull/4/files .

It may be in scope to put Qt aware versions of some of the core-callbacks from blue sky here (ex, table, some of the plotting) so it can be shared by {xi-cam, databroker-browser, bluesky-ui}.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should revisit this down the road a bit.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To elaborate, as long as we may use event-model in places, as an optional dependency inside the widget, same as others listed above, we can wait on the decision of whether the library should take a position of whether widgets "should" do so where applicable.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, nothing blocks the library to create a section of:
Event Model Aware Widgets... or something like that...

Comment thread README.rst Outdated
Co-Authored-By: tacaswell <tcaswell@gmail.com>
@tacaswell
Copy link
Copy Markdown
Member Author

@NSLS-II/mily can people please approve this if / when they are happy with it?

Comment thread README.rst
- prefer numpy arrays, pandas dataframes, and xarray objects to support
richer 'bulk' data.
- define (simple) interfaces when needed, but prefer to ducktype
standard objects.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth clarifying that "standard objects" means Python built-in or widely-used data structures.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tweaked this wording a bit to refer to built in types and the bullet point above.

Comment thread README.rst
- data I/O code
- business logic

Related projects
Copy link
Copy Markdown

@leofang leofang Mar 19, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be related: https://github.com/leofang/ptycho_gui, a GUI based on PyQt5 to provide control and visualization of ptychography reconstruction.

Below is a short description we wrote for the GUI (unpublished yet, sorry):

For users’ convenience, we also provide a GUI for pre-processing the scan data, executing an ptychographic reconstruction, monitoring the result as the reconstruction progresses, and post-processing the obtained probe and object, as shown in Fig. 6. The overall framework of the GUI is built with PyQt5, and previewing the scan images, plotting error metrics, visualizing resultant images and so on, are handled using Matplotlib.

In the main panel, see Fig. 6a, users can load the scan data to be reconstructed (either from the NSLS-II Databroker [30] or an existing HDF5 file) and check the associated experimental parameters. Users can open the pre-processing panel, see Fig. 6b, with the loaded data, and it provides both automatic/manual bad-pixel and region-of-interest detection on the raw diffraction data. The pre- processing panel is also equipped with convenient functionalities such as panning and zooming in/out for better inspection of the images. After that, in the main panel, users can select up to two ptychography algorithms and configure the reconstruction parameters, such as the floating- point precision, the number of iterations, the number of GPUs (or CPUs) the code is to run on, etc. Once the reconstruction starts, the monitor panel in Fig. 6c is popped up so that users can monitor/navigate the progress of the reconstruction in a streaming (or static) manner. The communication between the frontend (GUI) and the backend (CPU/GPU ptychography code) is done via POSIX shared memory, enabled by the Python package posix_ipc which provides a wrapper over the POSIX API.

The clean separation of UI design, logic implementation, and actual computation allows the GUI to be easily maintained. To smoothly manage all functionalities provided in the GUI, it is multi- threaded and managed using the signal-slot and the QThread mechanisms in the Qt framework, even though the GUI itself only runs on one CPU core. Lastly, the GUI also provides a batch mode, with which users can process over several sets of scan data in the same setting.

ps. sorry for late reply

Copy link
Copy Markdown
Member

@mrakitin mrakitin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general. Left a few minor corrections.

Comment thread README.rst
This is GUI for browsing runs that are stored in the databroker.

bluesky-qtui
Qt widgets for capturing user input to `blueksy
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Qt widgets for capturing user input to `blueksy
Qt widgets for capturing user input to `bluesky

Comment thread README.rst
`databroker-browser <https://github.com/NSLS-II/databroker-browser>`__
This is GUI for browsing runs that are stored in the databroker.

bluesky-qtui
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
bluesky-qtui
`bluesky-ui <https://github.com/NSLS-II/bluesky-ui>`__

Comment thread README.rst
Domain specific plotting and GUI widgets for X-ray science

`adviewer <https://github.com/pcdshub/adviewer>`__
AreaDetector configuration and viewing / based on typhon, pydm, and ophyd
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we mention NSLS-II ISS GUI <https://github.com/NSLS-II-ISS/profile_collection/blob/master/startup/99-gui.py>__ and XFP GUI <https://github.com/NSLS-II-XFP/profile_collection/blob/master/startup/99-gui-ht.py>__?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants