Live plotting using dash

[stavros11]

Implements live plotting for qcvv actions using the dash library, inspired by qiboteam/qibolab#132. Usage is as follows:

qq tiiq action_runcards/example.yml output_folder

will create data files in a directory named output_folder.

One can simultaneously run

liveqq output_folder

which will launch a dash server that checks the output_folder and plots all the data files that it contains. Plot will be live if the respective data yaml is being updated and static if the data file is not updated. If a file stops updating (action finishes), the live plot will be static automatically.

@andrea-pasquale, I created a new folder called plots/ and put an example plotting method there. If you prefer a different layout feel free to change this. Ideally live plotting should use the same plotting methods with reporting, to avoid code duplication. We just need to decide if we will go with plotly or matplotlib. Plotly has some cool out-of-the-box features (such as zoom) that could be useful for the html report too, but I am not sure if it is missing any other features compared to matplotlib. I have not checked how matplotlib (or mpld3) works with dash yet.

@scarrazza dash provides an easy way to produce html via Python. For example if you use the current liveqq in an existing output folder you get a static report of all logs in the folder. I am not sure if this is good enough to use for reporting though, particularly if it is possible to have links to other pages (like a full web up using flask).

[scarrazza]

@scarrazza dash provides an easy way to produce html via Python.

This idea sounds good to me, because we could use the server to render the live stream but at the end dump the static final version of these data. I assume we could have a single implementation of plotting/yaml/data functions for each action. Just a comment about a future feature, I forecast the need for a qq-compare tool which takes 2 reports and generate a single report, also here I believe this approach should work with minor changes.

[scarrazza]

@stavros11 thanks for that just few comments so I can update you about some ideas discussed with Andrea.

• we are planning to remove the platform option in qq and just write it inside the runcard, so qq can store a copy of this runcard inside the output folder, and we could upload the folder to a server and reproduce results in the future.
• I think we should always dump a static report after executing actions. Each action should come with instructions (functions) about: data storage, plotting and reporting. In fact, if we use this live plotting for the static report generation, then most likely this approach will simplify the code and reduce the amount of code duplication.

[scarrazza]

Suggested change

	liveqq = "qcvv:live_plot"
	qq-live = "qcvv:live_plot"

[scarrazza]

Poetry should include dash.

[scarrazza]

Please change PLOT_PATH with data_folder or something simpler for the user.
If you can please include docstrings so qq-live -h shows something useful.

[stavros11]

Thank you for the comments. I changed the action name to qq-live and updated its docstring.

Poetry should include dash.

I was not sure if should include it since live plotting was considered an optional feature. I included this now and there aren't any issues (like with qibolab) so it should be okay to keep.

• we are planning to remove the platform option in qq and just write it inside the runcard, so qq can store a copy of this runcard inside the output folder, and we could upload the folder to a server and reproduce results in the future.

Yes, Andrea updated me regarding your discussions and I agree with all the points and saving the action runcard in the output. Removing the platform option would also simplify things as the user should be able to pass all the input parameters, including the platform, from one place, in this case the (action)-runcard.

• I think we should always dump a static report after executing actions. Each action should come with instructions (functions) about: data storage, plotting and reporting. In fact, if we use this live plotting for the static report generation, then most likely this approach will simplify the code and reduce the amount of code duplication.

I agree with dumping a report. The live plotting page could in principle be used for report generation and this would indeed simplify the code. The main challenge though is how to dump the dash page to HTML, which should be possible if the page is static, but maybe not straightforward since dash is not designed for static pages. Non-static pages can probably not be dumped but this we don't need anyway.

I guess that once you decide on a template/format for this report, we can check if it is something we can produce easily by extending this live plotting code or if a different approach is needed.

[stavros11]

@scarrazza I had a quick look into exporting the dash page as a static HTML and I am not sure how easy and stable it is, for example see plotly/dash#145 and plotly/dash#1056. I tried the gist from the second issue for our current live plotting page and it saved the layout but the plots are empty. I also tried to save the server page directly from the browser but this gives a very large HTML file that does not show anything when opened with a browser.

Saving plotly figures to HTML is possible using fig.write_html and it keeps the interactive plotly features (such as zoom). The html code this generates is mostly javascript, but it can be opened as a standalone page without the need for a server.

An approach to get a static report from the live plotting page would be to write our own parser which loops through the html layout defined in serve_layout, ignores the interactive features (such as dcc.Interval) and parses only static elements and graphs (using fig.write_html). I can give a try to do this, however I am not sure how robust it will be when the report layout becomes more complicated.

Alternatively, we could consider having different infrastructures for live plotting and reporting and share functions whenever this is possible, for example the plotting functions could be the same if we use plotly in the report.

[scarrazza]

Thanks for checking. Supposing we are planning to use a custom html/css template the server_layout is most likely a good candidate in combination with fig.write_html. Could you please give a try, with plain html, and see if this approach is really possible?

[stavros11]

Closing in favor of #19.