Pool and Sessions in conode

Summary

Summary views and the subgraph contained within them enable conode users to:

1. Run different experiments on the same scenario set. For example with different stacks, or different parameters.
2. Organise classes of scenarios and runs (or sessions) in a way that it is auditable in the future.
3. Keep track of different runs of a certain stack, or multiple stacks, on specific scenario datasets.

While there is some overlap between the workflows defined above, the real difference in use cases between 2 & 3 is running new experiments vs keeping track of past experiments.

We will walk through the key node types contained within these views, namely Api key, Pool and Session nodes, and briefly highlight their role and use.

Api Key

The Api Key is usually located at the centre of your Summary Overview. This node is unique to each user account, whether it be a company-wide account or individual user within an organisation, and acts as a header node to all data available to that account. As such, it should help you navigate quickly to the subset of the graph that is relevant to you.

This Api Key has a number of successor nodes, but the two of most importance are the following: Pools is a header node which groups specific subsets of scenarios. Sessions groups the results of a simulation experiment run on a pool (i.e. group of scenarios).

There can be any number of pool nodes, grouped under the Pools header.

Pools

As introduced above, pools are essentially just nodes that organise subsets of scenarios, where the subsets can be groups based on any flexible classification you need.

For example, if you wish to run an experiment on a set of scenarios that test the 'unprotected-turns' feature of your stack, you could select all the unprotected turn scenarios that are available to you (see Scenario Selection workflow).

and group them under a pool node. Another common use of a pool node is a distributed selection of scenarios which you regularly test on (weekly, or after every significant change to your stack for example) to keep track of performance improvements. We’ll explain this use case in more detail in the Sessions part of this document. As a final example, at conode we use pool nodes internally to group - and hence - which scenarios we included in each of our customer ‘deliveries’.

It is worth noting that pools do not need strict partitions; scenarios can be in as many pools as one wants. The individual scenario nodes are the successors of each pool header node, and are connected up in no particular order.

Sessions

As mentioned above, pools can be used to group sets of “input” (pre-simulation) scenarios on which we would like to
run a simulation session to test the performance of a certain stack, or certain sensors. As every simulation run will have a particular set of parameters associated with it, the role of session nodes is to capture all these details.

In Figure 3 we have two example session nodes, with labels mu-unprotected-v2.. and mu-unprotected-v3... We have expanded the latter to its direct successors to better illustrate the session nodes - let's look at this in more detail.

The two successors of session mu-unprotected-v3 shown in Figure 3 are described below. - completed: This node keeps track of which scenarios from the pool have been run through simulation, whether the run was successful or not. The date-times at which each scenario was run is stored as the edge weight between the completed header node and individual scenario node. Note that the scenario nodes connected to this header are the same nodes that are connected to the pool header, see Figure 3 for an example of this structure. - results: This node keeps track of all post-simulation scenarios. For example, the scenarios in which the ego vehicle was replaced by a customer’s stack, and hence may have followed a different path to what was outlined in the pre-simulation version of the scenario. Every post-simulation scenario is connected directly to its equivalent pre-simulation scenario, see Figure 3 for an example of this structure. The post-simulation scenario nodes are again connected to the results header with an edge weight equal to the date-time at which they were run.

The structure of the graph allows us to store any and all parameters we feel are necessary to differentiate the setup of each session, for example, the model of the customer’s stack which was used when running the simulation session. These parameters are the two predecessors to the session node in Figure 3. Storing all relevant information makes it easy to compare sessions to each other, see differences on the same/similar scenario pools or how one image compares on different pools.

.