Description:

We need to show that the OneMax optimisation run can be supported on this platform. This means creating a new Python script for the run and also a new plugin to visualise 1D data as a line graph with the fitness values increasing over the generations.

I need to look at the types of data we may need to additionally store e.g. fitness values and make support for storing 1D data.

Acceptance criteria:

• Send OneMax optimisation run data,
• Store run information correctly and supported 1D/fitness values for generations
• Create a line graph visualisation for the data in the frontend as a new plugin.

Description:

Currently, a run information card on the homepage increases in height when the run title exceeds the max-width of the card. A solution would be to add an overflow to the run title so when it exceeds the width we just add ellipses and cut off the rest of the title. The full title would be displayed on a mouseover.

Acceptance criteria:

• The height of all run cards are equal.

Description:

Add the appropriate testing frameworks i.e. Jest, Cypress for unit and usability/integration testing. Set up backend testing frameworks and overall code coverage.

Acceptance criteria:

• Add Jest support for frontend,
• Add Cypress support for frontend,
• Add nyc/mocha for unit testing backend,
• Add chai-http for integration testing support on backend,
• Add support for testing MongoDB through unit and integration testing,
• Add testing support for socket.io,
• Add code coverage support (coveralls).

Description:

Allow for PCA/MDS (multidimensional scaling); possible in JavaScript or Python.

Description:

Conduct a design study (need to explore what is required for this).

Description:

Add support for 3D visualisations. A good way of testing this is through three objective visualisations. This will however be difficult (or not possible) with the default D3.js we have bundled with the frontend.

For this, it may be possible to make use of Plotly.js (https://plotly.com/javascript/) and 3D scatter plots (https://plotly.com/javascript/3d-scatter-plots/). Since this library is originally in JavaScript it will need the correct typings in order to work with TypeScript otherwise the plugin will need to use React with JavaScript instead.

Acceptance criteria:

• Backend supports three objective data and stores them correctly,
• Three objective plugin to visualise the data (scatter graph) using an appropriate library,
• Frontend and plugin work correctly as it should like the other plugins.

Description:

As an update, I am currently working on re-organising the content on the visualisation container to show additional run information.

I want the visualisation to also show a D3 tooltip when hovered indicating the point x,y locations, similar to this example:

Acceptance criteria:

• Show tooltip over each point in the visualisation with the exact X and Y.

Description:

We need to be able to store generation data in the frontend state especially if we require previous generation data for the visualisation. If we change to storing data in the frontend we can just request the generation data we need by giving a list of the generations to the server and then add the data to the state when we receive it.

This avoids receiving the information we already have and means we won't have to make further requests to the server for the same data during replays or when seeking when using the generation slider.

Acceptance criteria:

• Store generation data in the frontend after requests are made,
• Use the stored data next time it is needed when seeking or replays are made.

Description:

Conduct further usability testing with a greater number of participants.

We are looking to develop a "Visualisation-as-a-Service".

Description:

Prevent confusion in setting up routes/registerRouteAction and simplify the process

Description:

Investigate to see if React Query could be used instead of Redux since it has the ability to cache data.

Description:

Make use of MongoDB Maps to store the generation data more easily rather than having one large array.

Acceptance criteria:

• Stores populations under a generation object using MongoDB Maps,
• Updates the generation number with each write to the database (without other writes to the database interfering).

Description:

Heroku announced the removal of their free tier. Remove and archive references to Heroku and deployment instructions.

Acceptance criteria:

• All Heroku references and files are archived.

Description:

A user may want the replay to be a lot slower, maybe display 1 generation per second. At the moment the replay is as quick as we can receive and display the data on the frontend.

Acceptance criteria:

• Field/slider to set the speed of the visualisation, or with a toggle to turn the speed on or off (if off it will run as quick as we receive the data).

Add continuous integration using Travis CI and add support for unit testing using jest and support for integration testing using Cypress.

Description:

Add state management to the frontend using Redux and support Redux actions which deals with handling WebSockets and HTTP requests.

Acceptance criteria:

• Add Redux to frontend
• Configure Redux store, actions, reducers and types

Description:

This may not necessarily be an issue but this is due to us loading the plugins initially on a page refresh or load and causing them to mount initially. This does not cause a render of the plugin but shows that the plugin has been mounted and it can prevent the plugin which supposed to be rendered on the page from rendering until all plugins are loaded.

Description:

We are currently sending data to the server although the client at the moment does not say when the operation has been complete without manually checking the data in the database. The client needs to know when all the data has been processed.

Acceptance criteria:

• Client is notified once all data has been processed by the server
• The processing thread stops once it has been complete.

Description:

There are two errors when loading a plugin in the frontend. The first is that it loads multiple times on the page (possible due to re-renders?) (https://single-spa.js.org/error/?code=41).

The other error is due to the fact that singleSpa.start() is not called. This is most likely due to the plugin loading on all the pages but we want it to be rendered only when the user visits the data page.

Acceptance criteria:

• Plugins are not loaded multiple times on the page,
• The plugin is not loaded at the home or any other page except for the data page (this should stop the second error from occurring).

Description:

Load settings from a file, this will hold the configured plugins/visualisations.

Acceptance criteria:

• Load the settings information from a file
• Settings involves the plugins/visualisations

Description:

Support parallel coordinate plots as a plugin in the frontend. An example of drawing parallel co-ordinate plots in D3.js is shown in this example. We can make use of the current DTLZ data for the time being to draw them.

Acceptance criteria:

• Parallel co-ordinate plots can be drawn using D3.js,
• Visualise DTLZ data using parallel coordinate plots.

Description:

It might be a good idea to move this to use GitHub Actions instead of using TravisCI. There is a training tutorial by GitHub here to learn how to use GitHub Actions.

Description:

Provide the option for the user to replay the optimisation run for a running or complete run. For a running optimisation run, play the optimisation up until the current generation (or until the current data received). All the required data in order to replay the run should be fetched.

Acceptance criteria:

• Provide a button to replay the optimisation,
• Replay from the start to the current data received,
• Provide pause/replay options and fetch data accordingly.

Description:

Add a Slider component (similar to that found in Slider Material UI) to show the generations that have been added to the database.

Acceptance criteria:

• Able to slide between the generations that have been stored in the database,
• The slider updates when receiving new generation information,
• Able to scroll back through Pareto front estimations with the plugin loaded,
• There should be a pause and replay button alongside the slider (left of the slider),
• Controls include textbox and button to enter generation number to view,
• Able to enter a generation and click view to load its data,
• Ensure that there are no side-effects from using controls e.g. hooks firing multiple times.

Description:

All visualisations need to be provided in real-time, as a result when optimisation runs are in progress their data will need to be visualised as it comes in. The initial prototype will plot random values to the already generated scatter plot in D3.

We will need to leverage WebSockets (through [Socket.io]) in order to communicate data in real-time and also allowing for two-way communication between data point generation script and server and frontend to server.

Task on planner

Acceptance criteria:

• Data is sent from a python script to server
• Data can be sent from server to frontend
• Frontend visualise data in realtime and updates visualisations as time progresses

Description:

When observing adding the sample data points, we can see that not all have been added.

Acceptance criteria:

• All data is stored in the database.

Description:

Make use of the scatter graph to create a Pareto front estimation graphs using the DTLZ1 and DTLZ2 sample data.

Acceptance criteria:

• Shows all the generations data as it comes in
• Plots the solutions from each generation on the graph as a Pareto front estimation

Description:

At the moment the build is failing due to the frontend package installation not finding the frontend-common library to install.

Acceptance criteria:

• Deployment to Heroku functions correctly
• settings.json and deploy-settings.json is copied into the build folder for the frontend

Description:

Set up a continuous deployment solution. We can make use of Heroku to deploy the React frontend and backend server/API.

Acceptance criteria:

• Build and deploy React frontend on Heroku
• Deploy the backend to another Heroku to serve the API
• Allow communications between the backend and client optimisers

Description:

It seems any libraries we use via CDN defined in the public/index.html in plugins do not load. Instead, it has to be placed on the front-end in order for it to load. The libraries that a plugin uses need to be able to be used as packages or loaded from CDN in the plugin.

This is not an exact bug since the "index.html" in each plugin is for it to run independently of the frontend in development i.e. this is why we have separate React CDN links in there. However, for libraries like Plotly where the example we are using require a CDN, we may need to use another method to fetch the library.

Description:

Create a common library which will hold shared API calls or components.

Acceptance criteria:

• A shared common library that can be imported for use by visualisation plugins
• Contains functions to API and websocket data
• Contains creation of a single shared Redux store

Description:

One issue is that the settings JSON files in packages/frontend/public folder is not being found and copied to the build folder. The main error during the end to end test stage of the build on TravisCI is because a timeout occurs waiting for the frontend to start on port 3000.

Acceptance criteria:

• Settings files are copied successfully to the build output folder (including e2e-settings.json),
• Frontend build is successful and runs locally on port 3000.

Description:

The backend might crash locally or on Heroku when receiving a large volume of data through websockets to update into the database. This seems to be due to memory allocation/it runs out of memory?

Simply sending data one by one is no longer appropriate, there needs to be an alternate approach to send in data.

Acceptance criteria:

• The backend does not crash when receiving lots of data.

Description:

At the moment after one optimisation run finishes the client does not exist, we need to be able to start a new optimisation run after one completes and use createRun and need to clear the queue after a run finishes.

Acceptance criteria:

• Be able to do additional runs after one is complete.

Description:

Make use of single-spa to serve visualisations as separate "plugins" to frontend.

Acceptance criteria:

• Created plugins are separate to frontend
• Plugins loaded into frontend
• Plugins make use of common data available in frontend

Description:
The data which is received from the Python script needs to be saved into a MongoDB.

Acceptance criteria:

• The data sent identifies an optimisation run (i.e. title, date/time, types of graphs to render on) and is saved with a run ID
• The optimisation data itself is stored in the database (for this we are using 2D data with only x,y co-ordinates).

Description:

The server running out of memory was due to the concurrent writes to the MongoDB and the saves would accumulate a lot of memory until the server runs out of heap memory to allocate.

We need to either change the way we send (currently in batches with the size according to the population size) or improve the time it takes to send all the data to the server.

Acceptance criteria:

• Improve the time it takes to send the data
• The server does not run out of memory or crash due to writing to the database.

Description:

When changing the location to the plugin page (/runs/:runId/visualisations/:visualisationName/data) the plugin fails to load. This is not the case when visiting directly. This could be the fact that the plugin will load directly onto the page upon loading but will not load when the "div" is just inserting into the DOM when navigating to the new page.

We need to work out a way to manually refresh the page or the component or trigger a re-render on the whole plugin.

Acceptance criteria:

• The plugin displays when navigating to it from another page in the website.

This can be done with CodeCov when needed.

Description:

When a client is disconnected during a run, the run information e.g. the total generations, completed status, needs to be updated otherwise we see the slider provide the option to scroll to generations that have not been received.

Acceptance criteria:

• Slider does not show generations that have not been received,
• Total generations updated with the actual received when the client is disconnected,
• Run status is changed from completed to stopped (or similar).

Description:

Viewing at 100% on Chrome (on a 15-inch laptop screen) is causing the optimisation run page to move left and right due to the vertical scrollbar appearing every time the plugin is re-rendered on new data.

Acceptance criteria:

• Prevent vertical scrollbar appearing on plugin data re-render.

Description:

The frontend needs to show a list of the visualisations available for an optimization run. This will allow the user to select it and open the graph from which can they can then stream the real-time data to the frontend or playback a completed optmisation run.

Acceptance criteria:

• List of graphs supported by the optimiser
• Click on the graph brings up the graph with the relevant data in real-time or playback of a completed run.

The graphs re-render and appear on top of each other (visible when you see multiple x,y axis labels) when parameters are changed. Any currently rendered graphs and data need to be cleared before they are rendered again in the useEffect.

Description:

When connecting to an ongoing optimisation run, visualisation data that has already been saved can be fetched and sent to the frontend and then the real-time data can be streamed.

Acceptance criteria:

• Data fetched from server based on generations

Description:

Show a list of the currently running client optimisers and the completed optimiser on the landing page.

Acceptance criteria:

• API returns all the optimisation runs (active and completed)
• There a list of active optimisation runs
• There is a list of completed optimisation runs.

Description:

Allow for a "plugin"/child application to work with the frontend (parent). SciGateway is being used as a reference and some of the single-spa related code is being used.

Acceptance criteria:

• The frontend can load plugin applications which have been built and served,
• The plugin information is loaded from the plugin settings/configuration,
• Plugins can be served on custom routes.