Application file structure¶
Applications are organized into directories: all source code entry points and configuration files relating to an application must be in the same directory.
Quantum network applications typically involve multiple parties, each on a separate node in the network. We refer to these parties as roles. For example, a teleportation application might have two roles: a sender and a receiver.
An application directory consists of the following files:
Application source code. These are Python source code files with names starting with
app_
, e.g.app_alice.py
. There should be one file for each ‘role’ involved in the networked application.Application input. Each role can have a YAML file specifying the inputs to the application. Each role has its own local inputs. Names correspond to the roles in the application. For example, the role ‘sender’ has an input file
sender.yaml
.Network configuration. A single YAML file
network.yaml
specifying characteristics of the simulated network. See below for a detailed description of the expected format.Role-network mapping. Roles are logical concepts related to the application, and not directly tied to a physical (simulated) node. In the
roles.yaml
file you can specify which role (i.e. whichapp_<role>.py
file) runs on which network node.
Tip
The netqasm new
and netqasm init
commands automatically create the above file types.
File content format¶
Application source code¶
Each app_<role>.py
file should have a main
function.
See for more details Using the SDK.
Application input¶
A <role>.yaml
file should contain a simply dictionary of inputs.
For example:
theta: 3.1415
x: 1
Network configuration¶
See the NetworkConfig
dataclass.
Role-network mapping¶
The roles.yaml
file should contain a simple list of key-value pairs.
Each key should be a role name and each value a node name occurring in the network configuration.
Results and logs¶
Running an application produces two kinds of output: application results and log files.
If it doesn’t exist already, a log
directory is automatically created in the application directory.
In it, for each run of the application, a directory is created with a name indicating the time it was generated, e.g. 20201117-104744
.
For convenience, the last directory is always copied into a directory called LAST
, so in most cases you can just look into log/LAST
for the relevant output.
The output files are the following:
Application results. Application-specific results are written to
results.yaml
.Instruction logs. The simulator logs which NetQASM instructions it executes on each simulated node to a YAML file. For each
<node>
, a file<node>_instrs.yaml
is generated.Network log. Events related to the network and that are not local to one specific node are logged to
network_log.yaml
. These event currently only include entanglement generation events.Classical communciation logs. For each
<role>
, a file<role>_class_comm.yaml
is generated with all messages that are sent or received to/from that role.Applicaton logs. Applications can also log custom information to a file. An ‘application log’ from a
<role>
ends up in<role>_app_log.yaml
.
Output file contents¶
Application results¶
The results.yaml
file contains the Python directories that are return
ed at the end of the main
function in each role’s source code.
Instruction logs¶
A <role>_instr.yaml
contains a list of all NetQASM instructions that were executed by <role>
, in chronological order.
Each log statement includes the instruction type, and the time at which it was executed. It also includes the states of the qubits in the network (across all nodes) and which of these are entangled or not. Entangled qubits appear in the same qubit group.
This information is about the states directly after the instruction is executed.
See the InstrLogEntry
dataclass for the format of each log entry.
Network log¶
The network_log.yaml
contains a list of all entanglement events that happened in the simulated network, in chronological order.
As in the instruction log, the qubit states and groups are given as they are immediately after the event.
Two events (called stages) exist: START
(entanglement generation has started) and FINISH
(entanglement has successfully been generated).
Furtermore, there are two types of entanglement generation:
MD
(Measure Directly): upon successful generation, immediately measure the two (one in each node) qubits. So, directly after aFINISH
event of typeMD
, the corresponding qubits do not appear in the qubit information.
CK
(Create and Keep): upon successful generation, keep the qubits alive. The corresponding qubits appear in the qubit group information, and are (obviously) entangled.
START
events do not give information about the type. This is only given at FINISH
events.
MD
events (at the FINISH
stage) have additional information BAS
and MSR
.
These are the bases (one for each node) used for the (immediate) mesaurement, and the mesaurement outcomes themselves.
See the NetworkLogEntry
dataclass for the format of each log entry.
Classical communciation logs¶
Each <role>_class_comm.yaml
contains a list of all messages that were sent or received by <role>
, in chronological order.
See ClassCommLogEntry
dataclass for the format of each log entry.
Application logs¶
Each <role>_app_log.yaml
contains a list of custom log statements coming from app_<role>.py
.