Communication protocol

The actions and conventions that specify the TAS communication protocol can be found below. They build up on the general part of the communication protocol.

Actions

Action

Specific entries in data

Description

Client → Server

Server → Client

ping

  • method

  • version

Client checks connection and gets information about the server.

method: string
Method used for the server
version: string
Version of the server

reset

  • mode

  • axes

  • offset

  • limits

  • level_backgr

  • thresh_intens

  • travel_cost_max

  • scenario_name

Client resets the server for a new scan.

mode: string
Currently, only “single” is available
axes: list of 4D lists of floats
Axes in \(\mathbf{Q}\)-\(E\) space
offset: list of floats
Offset for the axes
limits: list of two 2D lists of floats
Limits of the scan area, length same as that of axes
level_backgr: float, optional
Value for background level
thresh_intens: float, optional
Value for intensity threshold, larger than level_backgr
travel_cost_max: float, optional
Maximum value for travel costs (used for normalization), default is 1.0.
scenario_name: string, optional
Name of scenario, included in name of log files if specified

result

  • locs

  • counts

  • matrices_ellipses

  • travel_time

  • counting_time

  • travel_cost_grid

  • travel_cost_values

Client sends results of measurements (counts) to the server. A discretization of the cost function at the current location locs[-1] can also be provided, if applicable.

locs: list of nD points
Measurement locations
counts: list of pairs
Pairs of detector and monitor counts, length same as that of locs
matrices_ellipses: list of n x n matrices
Matrices encoding an ellipse shaped zone that should be excluded from suggesting new locations in, length same as that of locs
travel_time: float
Time needed to move axes for counting at locs
counting_time: float
Time needed to count at locs
travel_cost_grid: list of nD points, optional
Grid in hyperrectangle given by limits for cost function
travel_cost_values: list of floats, optional
Cost function values at locations in travel_cost_grid, given if and only if travel_cost_grid is given, length same as that of travel_cost_grid

next_loc

  • loc

  • stop

Client requests the next location to measure at and whether it should stop the experiment at the server.

loc: nD list of floats
Next location
stop: bool
Boolean specifying whether the experiment should be stopped

heuris_experi_param

  • level_backgr

  • thresh_intens

Client requests heuristically computed experiment parameters at the server. If the computation is not possible, the server returns None values.

level_backgr: float
Value for background level
thresh_intens: float
Value for intensity threshold, larger than level_backgr

problem_locs

  • locs

  • matrices_ellipses

Client informs server about problem locations.

locs: list of nD points
Problematic locations
matrices_ellipses: list of n x n matrices
Matrices encoding ellipse shaped zones that should be excluded from suggesting new locations in, length same as that of locs

state_internal

depending on method

depending on method

Client requests the internal state of the approach (see table below) at the server.

stop

Client stops the experiment at the server.

Internal states

Server method

Data

Description

Client → Server

Server → Client

GPR

  • num

  • grid

  • means

  • stds

num: list of ints or int Number of points for each dimension in grid, length is \(n\) (if list)

grid: list of nD points Grid in hyperrectangle given by limits

means: list of floats Posterior mean function of log-GP at locations in grid, length same as that of grid

stds: list of floats Posterior standard deviation function of log-GP at locations in grid, length same as that of grid

Conventions

  • Each experiment starts with reset.

  • Each initial measurement point is sent via results.

  • The first message with next_loc triggers the initialization of the method at the server. Note that during initialization, which usually takes some time, the server responds with busy = True.

Example workflow

Test connection:

  1. Client → Server: ["ARIANE", "", "ping", "{}"]

  2. Server → Client: ["ARIANE", "", "ping", "{ success: True, method: 'GPR', version: '0.0.1' }"]

Reset server:

  1. Client → Server: ["ARIANE", "", "reset", "{ mode: 'single', axes: [[1, 0, 0, 0], [0, 0, 0, 1]], offset: [0, 1, 1, 0], limits: [[1, 3], [2, 9]] }"]

  2. Server → Client: ["ARIANE", "", "reset", "{ success: True }"]

Initialize server:

  1. Client → Server: ["ARIANE", "", "result", "{ locs: [[1, 2]], counts: [[30, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]

  2. Server → Client: ["ARIANE", "", "result", "{ success: True }"]

  3. … (client sends all initialization points)

  4. Client → Server: ["ARIANE", "", "result", "{ locs: [[3, 9]], counts: [[12, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]

  5. Server → Client: ["ARIANE", "", "result", "{ success: True }"]

  6. Client → Server: ["ARIANE", "", "next_loc", "{}"]

  7. Server → Client: ["ARIANE", "", "next_loc", "{ success: True, busy: True }"]

  8. … (client keeps sending messages with next_loc until the server is not busy anymore)

Main loop:

  1. Client → Server: ["ARIANE", "", "next_loc", "{}"]

  2. Server → Client: ["ARIANE", "", "next_loc", "{ success: True, loc: [2, 5.5] }"]

  3. Client → Server: ["ARIANE", "", "result", "{ locs: [[2, 5.5]], counts: [[170, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]

  4. Server → Client: ["ARIANE", "", "result", "{ success: True }"]

  5. … (client requests next locations and sends back the results until it stops the server)

Stop server:

  1. Client → Server: ["ARIANE", "", "stop", "{}"]

  2. Server → Client: ["ARIANE", "", "stop", "{ success: True }"]

This example represents an ideal workflow. The following actions were not considered:

  1. heuris_experi_param: to print experiment parameters for the user’s information, as these are computed heuristically if they were not specified during reset.

  2. problem_locs: to exclude ellipses around problem locations as potential regions for next measurement points.

  3. state_internal: to print or visualize a representation of the server method’s internal state.