Add Blank Lines
Available from: BaseSpace Clarity LIMS v3.0.0
Some instruments, such as Bioanalyzer and the ABI 7900HT, require input files that include a line for every well in a container.
Currently, files created with the sample input sheet generator can only contain data lines for each well that is in use and cannot add lines for empty wells. This extension script allows you to process a file in a certain format to add customizable lines for the empty container wells.
The Script
The addBlankLines script allows for the creation of files that require a line entry for every well in a container, including those wells that are empty.
To accomplish this, the script takes in an existing file, created with sample input sheet generator, and processes it to add the new lines.
The script reads the file and separates it into header, data, and footer sections.
Using the API, the script obtains the container size, its unavailable wells, and the placement of each sample.
Using this information, the script runs through each possible placement and builds a full set of data. This includes a line for each empty well, in addition to all original lines of data. If desired, a line for each unavailable well may also be included using script parameters described.
The file is then rewritten with the header, full data, and footer.
ℹ️ The addBlankLines script overwrites the input file provided, replacing it with the new file that includes the additional container line entries.
Placement information is written using a numeric index that is converted from the LIMS well placement. The line information that is inserted for an empty well is provided to the script. This is controlled by the blankLineString parameter, described.
The logic that determines whether the script uses input samples and containers or output samples and containers is as follows:
By default the script will use outputs.
If there are no outputs or if the optional parameter -forceInputs true is configured, the script will use inputs.
Script Parameters and Usage
Parameter
Description
-i {URI}
LIMS step URI (Required)
-u {username}
The LIMS username (Required)
-p {password}
The LIMS password (Required)
-f {inputFileName}
The input file name (Required)
-l {logFileName}
The log file name (Required)
-h {headerRows}
The number of lines in the header (Required)
-sep {separator}
The separator to use for the file - COMMA and TAB supported (Required). See Parameters Details.
-b {blankLineString}
The string to be used for blank lines (Required). See Parameters Details.
-c {columnType}
The data type specified in the first column of the data - LIMSID and PLACEMENT supported (Required). See Parameters Details.
-pre {indexPrefix}
The prefix to be included before the index of each well in the file output (Optional). See Parameters Details.
-forceInputs {forceInputs}
Provide as "true" to force the script to use the input samples and container when processing, even if output samples and containers exist. (Optional). See Parameters Details.
-countUnavailable
Provide as "true" to include unavailable wells in the placement index count (Optional). See Parameters Details.
-addUnavailable
Provide as "true" to include unavailable wells as entries in the updated file (Optional). See Parameters Details.
Parameter Details
Rules and Constraints
The script operates with the following constraints:
The input file and log file to update must exist locally.
Only supports TAB and COMMA as separators in the file.
Only supports processing one container at a time.
Can only use the first column of the data and requires either well placement or LIMS ID as values in this column.
Indexing always is done from left to right, top to bottom.
The well placement format in the original file must be alphanumeric (eg A1), or separated by a colon (eg 1:1).
As designed, the script supports processing one container only. As such, any step on which it is run must use either a single input container or a single output container, depending on which type of container you expect the script to use (see forceInputs).
Configuration
The script should be configured to run after the creation of a file occurs - either within the same automation call or as a separate automation triggered after the call that generated the file.
It can also be configured standalone for files that are locally accessible.
Example Automation Strings
Last updated