Skip to content

Commit 918f204

Browse files
minknowbotminknowbot
committed
Version 6.5.2 bump
1 parent 4cf52ef commit 918f204

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

41 files changed

+4850
-3953
lines changed

‎proto/minknow_api/acquisition.proto‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -732,6 +732,8 @@ message AcquisitionConfigSummary {
732732
bool fastq_reads_enabled = 5;
733733
// Determine if pod5 reads were enabled for the run.
734734
bool pod5_reads_enabled = 22;
735+
// Determine if bam reads were enabled for the run
736+
bool bam_reads_enabled = 26;
735737

736738
// This field has been removed
737739
// Since 5.8

‎proto/minknow_api/data.proto‎

Lines changed: 59 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -106,26 +106,31 @@ service DataService {
106106
option idempotency_level = NO_SIDE_EFFECTS;
107107
}
108108

109-
// Call this to force re-evaluating the channel states. This will make sure the next
110-
// channel state evaluated will be 'unclassified_following_reset'. If the analyser is behind,
111-
// and older data will come for evaluation, it will result in changing the state to 'pending_manual_reset'.
112-
// So typically, after a resetting the channel states, the user would see in the bulk file
113-
// 'unclassified_following_reset', 'pending_manual_reset', 'pending_manual_reset', until the relevant data
114-
// comes through to the analyser and it will start outputting the normal channel states again.
115-
// If the analyser is not behind, the user should ideally see just the 'unclassified_following_reset' state.
116-
//
117-
// This call is blocking - it will return from the rpc when it would have processed the
118-
// 'unclassified_following_reset' in the analyser. If the rpc takes more than 1 minute
119-
// it will exit with the ABORTED status. This can happen if the analyser is more than 1 minute behind
120-
// for example (in practice it shouldn't be the case). If the RPC exits with the ABORT status, it means
121-
// the channels are to be reset in the future, but the analyser did not reach that point yet.
122-
//
123-
// Only one of these can be executed at a given time. If multiple threads call this simultaneously,
124-
// it will execute the first request and it will exit with FAILED_PRECONDITION for the rest. If an RPC
125-
// exited with the ABORT status, another RPC can immediately be started. The failed RPC would have not
126-
// reset the channel states, and the user could try again. The second RPC will return as soon as the first
127-
// reset happens, so this will not be necessarily waiting for the second acquisition index to be
128-
// processed.
109+
// Call this to force re-evaluating the channel states. This will make sure the next channel
110+
// state evaluated will be 'unclassified_following_reset'. If the analyser is behind, and older
111+
// data will come for evaluation, it will result in changing the state to
112+
// 'pending_manual_reset'. So typically, after a resetting the channel states, the user would
113+
// see in the bulk file 'unclassified_following_reset', 'pending_manual_reset',
114+
// 'pending_manual_reset', until the relevant data comes through to the analyser and it will
115+
// start outputting the normal channel states again. If the analyser is not behind, the user
116+
// should ideally see just the 'unclassified_following_reset' state.
117+
//
118+
// Note that this will not clear any locked channel states - you must call
119+
// unlock_channel_states() for that.
120+
//
121+
// There is no guarantee that the reset will be visible in the channel states stream by the time
122+
// this call returns. If acquisition is paused at the time of the call, the channel states
123+
// streams may reflect the previous channel state (from before the reset) until acquisition is
124+
// resumed.
125+
//
126+
// It is guaranteed that the data resulting from any device settings changes made after this
127+
// call returns will be processed after the reset. So, for example, if reset_channel_states() is
128+
// called and then device.set_channel_configuration() is called to change the mux of one of the
129+
// reset channels, the channel state for that channel will be reset before any data from the new
130+
// mux is evaluated.
131+
//
132+
// Only one call to this RPC at once is permitted. If a second call is made while another call
133+
// is in progress, the second call will return a FAILED_PRECONDITION error.
129134
rpc reset_channel_states (ResetChannelStatesRequest) returns (ResetChannelStatesResponse) {}
130135

131136
// Forces channels to be fixed on a custom channel state. The channels will not be re-evaluated until
@@ -143,25 +148,42 @@ service DataService {
143148
// While the this RPC has the power of forcing a channel to any valid state other than 'unclassified',
144149
// it is intended to be used with channel states that are designed for this functionality (i.e. that
145150
// are never evaluated).
146-
// Has to be called while acquiring data, fails otherwise.
147-
// The forced channels are reset (reset = every channel back to being evaluated) every time a
148-
// new acquisition sequence is started.
149-
//
150-
// NOTE:
151-
// Calls to lock_channel_states and unlock_channel_states cannot be done in the same time.
152-
// If any of these two is called while any of these is already running, the grpc will return
153-
// with an error.
151+
//
152+
// This can only be called while acquiring data. The forced state does not persist between
153+
// acquisitions, but does persist across pauses.
154+
//
155+
// There is no guarantee that the locked channel state will be visible in the channel states
156+
// stream by the time this call returns. However, if acquisition is paused at the time of the
157+
// call, the channel states streams should receiver an update with the new locked channel state.
158+
//
159+
// It is guaranteed that the data resulting from any device settings changes made after this
160+
// call returns will be processed after the reset. So, for example, if reset_channel_states() is
161+
// called and then device.set_channel_configuration() is called to change the mux of one of the
162+
// reset channels, the channel state for that channel will be reset before any data from the new
163+
// mux is evaluated.
164+
//
165+
// This RPC cannot be called concurrently with unlock_channel_states() or other
166+
// lock_channel_states() calls. Attempting to do so will return a FAILED_PRECONDITION error.
154167
rpc lock_channel_states(LockChannelStatesRequest) returns (LockChannelStatesResponse) {}
155168

156-
// Re-activates channels that have been turned-off with force_channels_to_state.
157-
// Note that 'turning off' refers to channel states only, everything else is still applied on the channel
158-
// (e.g. mux changes, saturation, commands etc)
159-
// No action is taken if the channel is already active.
160-
// Has to be called while acquiring data, fails otherwise.
161-
// NOTE:
162-
// Calls to lock_channel_states and unlock_channel_states cannot be done in the same time.
163-
// If any of these two is called while any of these is already running, the grpc will return
164-
// with an error.
169+
// Unlocks channels whose states have been locked by lock_channel_states.
170+
//
171+
// If the state for the channel was not locked, this has no effect.
172+
//
173+
// This can only be called while acquiring data.
174+
//
175+
// There is no guarantee that the unlocking of the channel state will be visible in the channel
176+
// states stream by the time this call returns. If acquisition is paused at the time of the
177+
// call, the previous locked state may remain in place until acquisition resumes.
178+
//
179+
// It is guaranteed that the data resulting from any device settings changes made after this
180+
// call returns will be processed after the unlock. So, for example, if unlock_channel_states()
181+
// is called and then device.set_channel_configuration() is called to change the mux of one of
182+
// the reset channels, the channel state for that channel will be unlocked before any data from
183+
// the new mux is evaluated.
184+
//
185+
// This RPC cannot be called concurrently with lock_channel_states() or other
186+
// unlock_channel_states() calls. Attempting to do so will return a FAILED_PRECONDITION error.
165187
rpc unlock_channel_states(UnlockChannelStatesRequest) returns (UnlockChannelStatesResponse) {}
166188

167189
// Get live reads sent in order to control sequencing behaviour.

‎proto/minknow_api/debug.proto‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,26 @@ service DebugService {
2121
rpc get_basecaller_server_state (GetBasecallServerState) returns (GetBasecallServerResponse) {
2222
option idempotency_level = NO_SIDE_EFFECTS;
2323
}
24+
25+
// Disconnect flow cell at a position
26+
// Preconditions:
27+
// - the position is a simulated position
28+
// The call is ignored if the flow cell at that position is already disconnected
29+
rpc disconnect_flow_cell(DisconnectFlowCellRequest) returns (DisconnectFlowCellResponse) {}
30+
31+
// Connect flow cell at a position
32+
// Preconditions:
33+
// - the position is a simulated position
34+
// The call is ignored if the position already has a flow cell connected
35+
rpc connect_flow_cell(ConnectFlowCellRequest) returns (ConnectFlowCellResponse) {}
36+
37+
// Simulate frame loss for a specified amount of time
38+
// The request will only trigger the frame loss once during
39+
// the next initiated acquisition.
40+
// Preconditions:
41+
// - The position must be a simulated position
42+
// - An acquisition must not already be in progress
43+
rpc simulate_frame_loss(SimulateFrameLossRequest) returns (SimulateFrameLossResponse) {}
2444
}
2545

2646
message GetBasecallClientState {}
@@ -36,3 +56,31 @@ message GetBasecallServerResponse {
3656
// This debug string with internal debug data, in practice it generally a JSON-formatted string.
3757
string server_state = 1;
3858
}
59+
60+
message DisconnectFlowCellRequest {}
61+
message DisconnectFlowCellResponse {}
62+
message ConnectFlowCellRequest {}
63+
message ConnectFlowCellResponse {}
64+
65+
message SimulateFrameLossRequest {
66+
// The duration for which the frame loss will occur.
67+
google.protobuf.Duration frame_loss_duration = 1;
68+
69+
// The frame index from which the frame loss will begin
70+
//
71+
// For simulated PromethIONs this equates to the frame index within a section
72+
uint64 start_frame = 3;
73+
74+
// Optional section index from which the frame loss will begin
75+
//
76+
// For simulated PromethIONs a section equates to a completed scatterlist
77+
optional uint64 start_section = 4;
78+
79+
// Optional number of times to repeat the failed transfers
80+
//
81+
// This will reset the frame loss on starting a new acquisition or
82+
// resuming acquisition on an existing signal reader.
83+
optional uint64 repeats = 5;
84+
}
85+
86+
message SimulateFrameLossResponse {}

‎proto/minknow_api/protocol.proto‎

Lines changed: 35 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -931,6 +931,36 @@ message ExternalOffload {
931931
// The `id`s associated with active external data offloads associated with the protocol
932932
// The offload status can be queried using `mooneye.offload_manager.watch_offloads()``
933933
repeated string offload_ids = 1;
934+
935+
// An adapted version of mooneye.OffloadLocation
936+
//
937+
// Since 6.5
938+
message OffloadLocation {
939+
// unique id of this offload location (uuid)
940+
google.protobuf.StringValue id = 1;
941+
942+
// name of this offload location
943+
string name = 2;
944+
945+
// Path of directory to offload to
946+
// Each worker actually offloads to a unique directory generated at path
947+
// which is "OffloadLocation.path / OffloadWorker.id"
948+
// path is s3 bucket if LocationType.S3
949+
string path = 3;
950+
951+
// Defines type of offload location
952+
enum LocationType {
953+
LOCATION_TYPE_LOCAL = 0;
954+
LOCATION_TYPE_NETWORK = 1;
955+
LOCATION_TYPE_S3 = 2;
956+
}
957+
958+
// location type
959+
LocationType location_type = 4;
960+
}
961+
962+
// mooneye offload location information
963+
repeated OffloadLocation offload_locations = 2;
934964
}
935965

936966
// From instance.proto
@@ -1556,8 +1586,11 @@ enum Action {
15561586
// This will only be sent if the can_pause capability has been set to true by a request
15571587
// in the current call to protocol_phase_management().
15581588
//
1559-
// If the protocol is not pausing or paused, this message should be ignored.
1560-
// Otherwise, the protocol should immediately respond with a ProtocolPhaseManagementRequest
1589+
// Since 6.5, this message will not be sent unless the protocol is in PHASE_PAUSED. A
1590+
// resume request received while the protocol is still pausing will be held back until
1591+
// the protocol has changed the phase to PHASE_PAUSED.
1592+
//
1593+
// The protocol should immediately respond with a ProtocolPhaseManagementRequest
15611594
// that sets the phase appropriated (eg: to PHASE_RESUMING).
15621595
ACTION_RESUME = 2;
15631596
// The protocol should trigger a mux scan.

‎proto/minknow_api/read_end_reason.proto‎

Lines changed: 14 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,31 @@
1-
syntax="proto3";
1+
syntax = "proto3";
22

33
package minknow_api.read_end_reason;
44

55
option java_package = "com.nanoporetech.minknow_api";
66
option objc_class_prefix = "MKAPI";
7-
option go_package ="github.com/nanoporetech/minknow_api/go/gen/read_end_reason";
8-
7+
option go_package = "github.com/nanoporetech/minknow_api/go/gen/read_end_reason";
98

109
enum ReadEndReason {
1110
All = 0;
11+
// The read end reason is unknown (should never be encountered in practice).
1212
Unknown = 1;
13+
// The read is still in progress.
1314
Partial = 2;
15+
// The channel configuration (eg: mux or test current) was changed.
1416
MuxChange = 3;
17+
// An unblock was requested via the device.unblock RPC.
1518
UnblockMuxChange = 4;
19+
// The signal level rose, and the read breaker interpreted this as the end of a read.
1620
SignalPositive = 5;
21+
// The signal level dropped, and the read breaker interpreted this as the end of a read.
1722
SignalNegative = 6;
23+
// An unblock was requested via the data.get_live_reads RPC.
1824
DataServiceUnblockMuxChange = 7;
25+
// The dynamic analysis configuration changed.
1926
AnalysisConfigChange = 8;
27+
// There was a break in the stream of data from the device.
28+
DeviceDataError = 9;
29+
// An explicit request to break the read was made via RPC.
30+
ApiRequest = 10;
2031
};

‎proto/minknow_api/run_until.proto‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -85,6 +85,26 @@ import "google/protobuf/timestamp.proto";
8585
// Criterion is met if the number of basecalled bases which pass filtering is greater than or
8686
// equal to the specified value.
8787
//
88+
// `coverage` (float)
89+
// The number of times a given reference genome is sequenced
90+
// Criterion will never be met if basecalling is not enabled or a reference is not supplied
91+
// Updates will not be supplied if basecalling is not enabled or a reference is not supplied
92+
// Criterion is met if the coverage amount is greater than or equal than the specified value
93+
//
94+
// `barcode_coverage` (float)
95+
// The number of times a given reference genome is sequenced and has also been identified to have an attached barcode
96+
// Criterion will never be met if basecalling is not enabled, a reference is not supplied, barcoding is not enabled, or the samples have no attached barcode
97+
// Updates will not be supplied if basecalling is not enabled or a reference is not supplied, barcoding is not enabled, or the samples have no attached barcode
98+
// Criterion is met if the coverage amount is greater than or equal than the specified value
99+
//
100+
// `bed_coverage` (float)
101+
// The same as `coverage`, with the addition that the bases have to be associated with a BED region
102+
// Criterion will also never be met if a BED file is not supplied
103+
//
104+
// `bed_barcode_coverage` (float)
105+
// The same as `barcode_coverage`, with the addition that the bases have to be associated with a BED region
106+
// Criterion will also never be met if a BED file is not supplied
107+
//
88108
//
89109
// Additional Run-Until Criteria
90110
// -----------------------------

‎proto/minknow_api/v2/README.md‎

Lines changed: 3 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,4 @@
1-
This section of the API is an under-construction replacement of the per-flow-cell-position APIs, such as:
1+
This section of the API is an under-construction replacement of the per-flow-cell-position APIs.
22

3-
## ProtocolService
4-
* list_protocol_runs
5-
* get_run_info
6-
* generate_run_report
7-
* clear_protocol_history_data
8-
9-
## AcquisitionService
10-
* get_acquisition_info
11-
* list_acquisition_runs
12-
13-
The above calls should be made to the usual manager port (9501/2) rather than to individual `control_server` ports.
14-
Each of the above calls will be modified to add a `run_id` field, or potentially a 'repeated' `run_id` for interacting with multiple protocols simultaneously.
3+
The calls should be made to the usual manager port (9501/2) rather than to individual `control_server` ports.
4+
Calls will be modified to add a `run_id` field, or potentially a 'repeated' `run_id` for interacting with multiple protocols simultaneously.

‎proto/minknow_api/v2/protocols.proto‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,7 @@ option java_package = "com.nanoporetech.minknow_api.v2";
66
option objc_class_prefix = "MKAPI";
77
option go_package = "github.com/nanoporetech/minknow_api/go/gen/v2/protocol";
88

9+
import "minknow_api/acquisition.proto";
910
import "minknow_api/protocol.proto";
1011
import "minknow_api/manager.proto";
1112
import "util/status.proto";
@@ -60,6 +61,38 @@ service ProtocolsService
6061
rpc list_protocol_runs (minknow_api.protocol.ListProtocolRunsRequest) returns (minknow_api.protocol.ListProtocolRunsResponse) {
6162
option idempotency_level = NO_SIDE_EFFECTS;
6263
}
64+
65+
// Sends out a 'clear history data' request to all flow cells.
66+
//
67+
// History data includes protocol protocol info, acquisition info and statistics.
68+
//
69+
// Also clears any persistence data that has been written to disk for those protocols which meet the criteria -- this
70+
// data will not be available after a restart.
71+
//
72+
// Does NOT clear experiment results (fast5, fastq, sequencing_summary, etc)
73+
//
74+
// Since 6.5
75+
//
76+
rpc clear_protocols_history_data(minknow_api.protocol.ClearProtocolHistoryDataRequest) returns (minknow_api.protocol.ClearProtocolHistoryDataResponse) {}
77+
78+
// Generate a run report and return the report data.
79+
//
80+
// If the protocol selected for report generation is already complete the report is a completed report, otherwise
81+
// the report will be from the in progress protocol.
82+
//
83+
// Since 6.5
84+
rpc generate_run_report(minknow_api.protocol.GenerateRunReportRequest) returns (stream minknow_api.protocol.GenerateRunReportResponse) {}
85+
86+
// Gets information about a acquisition run.
87+
//
88+
// If no run ID is provided, information about the most recently started acquisition run is
89+
// provided.
90+
//
91+
// Since 6.5
92+
rpc get_acquisition_info (minknow_api.acquisition.GetAcquisitionRunInfoRequest) returns (minknow_api.acquisition.AcquisitionRunInfo) {
93+
option idempotency_level = NO_SIDE_EFFECTS;
94+
}
95+
6396
}
6497

6598
message BeginProtocolsRequest

‎python/minknow_api/_version.py‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
__version__ = '6.4.3'
1+
__version__ = '6.5.2'

0 commit comments

Comments
 (0)