Simulations pane

[annehaley]

Summary

The Simulations pane introduced in this PR allows the user to create SimulationResult objects in the database and view existing results. After picking a Simulation type, the user must specify all required inputs, then they may run the simulation.

Details

For this PR, only one Simulation type is implemented, called "Flood Scenario 1". Simulation types (not to be conflated with SimulationResults) are not database objects. Rather, they exist as a hard-coded mapping of celery tasks. The simulation types populate the side-panel under "Available Simulations."

(Side note: this PR also switches the order of the "Available Layers" and "Active Layers" panels for consistency with the other panels' organization)

When the user selects a simulation type, the simulations pane appears for the selected type. The pane has two tabs: a tab to create a new SimulationResult object, and a tab to view existing ones. The tab to create a new one allows the user to specify all the inputs required for the selected simulation type. Once all required inputs are specified, the user may run the simulation.

The request to run a simulation creates a SimulationResult object, which it returns to the client and sends into a Celery task to fill in the output_data field. While the celery task is running, the client shows the SimulationResult object's input_args and modified_date, as well as a spinner while the output_data is undefined. While the spinner is shown, the client polls the server every two seconds for an update.

Once the celery task is complete, the client will receive the updated output_data on the target SimulationResult object and display it. In the case of "Flood Scenario 1", the output type is "node_failure_animation", so a specialized component called NodeFailureAnimation is displayed in the results section once output_data is defined. The node failure animation can be played forward or backward (with 1 second ticks) or the user can go directly to a step using the slider.

As the slider moves, the list of deactivatedNodes changes. The new value is equal to the node failure list, sliced to end on the index of the current tick. (On the second tick, deactivatedNodes contains 2 node ids.) As the list of deactivated nodes changes, the client sends a computeGCC request and updates the map with the response. This happens in the same manner as when the user manually updates the deactivated nodes.

The video attached below shows this behavior.

Results

uvdat_simulations_compressed.mp4

[jjnesbitt]

Looks good overall, tested locally. Just have a few questions/concerns

[annehaley]

Note: I realized that SimulationResults should also reference the City as their context (so similar simulations in different cities don't get confused). This change was made in 1cd52b8