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 |
Description |
|
---|---|---|---|
Client → Server |
Server → Client |
||
|
– |
|
Client checks connection and gets information about the server. method: string Method used for the server
version: string Version of the server
|
|
|
– |
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 , optionalValue for background level
thresh_intens: float , optionalValue for intensity threshold, larger than
level_backgr travel_cost_max: float , optionalMaximum value for travel costs (used for normalization), default is 1.0.
scenario_name: string , optionalName of scenario, included in name of log files if specified
|
|
|
– |
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 , optionalGrid in hyperrectangle given by
limits for cost functiontravel_cost_values: list of floats , optionalCost 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 |
|
– |
|
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
|
|
– |
|
Client requests heuristically computed experiment parameters at the server.
If the computation is not possible, the server returns level_backgr: float Value for background level
thresh_intens: float Value for intensity threshold, larger than
level_backgr |
|
|
– |
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 |
|
depending on method |
depending on method |
Client requests the internal state of the approach (see table below) at the server. |
|
– |
– |
Client stops the experiment at the server. |
Internal states¶
Server method |
Data |
Description |
|
---|---|---|---|
Client → Server |
Server → Client |
||
GPR |
|
|
|
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 withbusy = True
.
Example workflow¶
Test connection:
Client → Server:
["ARIANE", "", "ping", "{}"]
Server → Client:
["ARIANE", "", "ping", "{ success: True, method: 'GPR', version: '0.0.1' }"]
Reset server:
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]] }"]
Server → Client:
["ARIANE", "", "reset", "{ success: True }"]
Initialize server:
Client → Server:
["ARIANE", "", "result", "{ locs: [[1, 2]], counts: [[30, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]
Server → Client:
["ARIANE", "", "result", "{ success: True }"]
… (client sends all initialization points)
Client → Server:
["ARIANE", "", "result", "{ locs: [[3, 9]], counts: [[12, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]
Server → Client:
["ARIANE", "", "result", "{ success: True }"]
Client → Server:
["ARIANE", "", "next_loc", "{}"]
Server → Client:
["ARIANE", "", "next_loc", "{ success: True, busy: True }"]
… (client keeps sending messages with
next_loc
until the server is not busy anymore)
Main loop:
Client → Server:
["ARIANE", "", "next_loc", "{}"]
Server → Client:
["ARIANE", "", "next_loc", "{ success: True, loc: [2, 5.5] }"]
Client → Server:
["ARIANE", "", "result", "{ locs: [[2, 5.5]], counts: [[170, 100000]], matrices_ellipses: [[[625.0, 0.0], [0.0, 23.5]]] }"]
Server → Client:
["ARIANE", "", "result", "{ success: True }"]
… (client requests next locations and sends back the results until it stops the server)
Stop server:
Client → Server:
["ARIANE", "", "stop", "{}"]
Server → Client:
["ARIANE", "", "stop", "{ success: True }"]
This example represents an ideal workflow. The following actions were not considered:
heuris_experi_param
: to print experiment parameters for the user’s information, as these are computed heuristically if they were not specified duringreset
.problem_locs
: to exclude ellipses around problem locations as potential regions for next measurement points.state_internal
: to print or visualize a representation of the server method’s internal state.