Validating Illumina TruSeq Index Adapter Combinations
PreviousChecking for Index Clashes Based on Index SequenceNextScripts Triggered Outside of Workflows/Steps
Last updated
Last updated
When pooling samples, there are often numerous complex rules and restrictions regarding which combinations of adapters are acceptable.
As a method of applying custom business logic, it is possible to automate the verification of your pools using Clarity LIMS.
This example shows how to confirm the composition of pools before they are created, allowing the lab scientist to alter the composition of pools that have caused an error.
In this example, we will enforce the following Illumina TruSeq DNA LT adapter tube pooling guidelines:
The example script is configured to run on the Library Pooling (Illumina SBS) 4.0 process.
The EPP command is configured to pass the following parameters to the script:
An example of the full syntax to invoke the script is as follows:
NOTE: The location of Groovy on your server may be different from the one shown in this example. If this is the case, modify the script accordingly.
Assuming samples have been worked through the protocol and have reached the Library Pooling (Illumina SBS) 4.0 protocol step, the user pools the samples following the specified guidelines.
When the pools are created, the user attempts to proceed to the next page.
A message box displays alerting the user that a custom program is executing.
On successful completion, a success message displays.
Once the script has processed the input and ensured that all the required information is available, we process the pools to determine if they meet the required specifications.
The first challenge is to represent the adapter combinations in the script.
This is accomplished by a map comprised of the adapter names, indexed by their respective number, ie. AD001 indexed at 1.
Next, we define the three combination groups: 2 plex, 3 plex, and 4 plex.
This is achieved by creating a List of Lists, with the inner lists representing our combinations.
To facilitate the required fallback through lower plexity combinations, we store the combinations groups in a list, in ascending plexity.\
Once the combinations are defined, we need to create a method which will compare the actual combination of adapters in a pool with our ideal combinations. There are two cases we need to handle:
When we are comparing two equal plexity combinations.
When we are comparing a higher plexity pool to a lower plexity combination.
To handle the first case, we create a function that takes in our actual combination, and the ideal combination.
If the actual combination contains the entire combination, we remove those adapters. We then ensure that the leftover adapters are not in our Illumina TruSeq DNA LT adapter.\
The second case is similar to the first.
We create a function that takes in our actual combination, the ideal combination, and the amount of wildcards. A wildcard represents an 'any adapter' condition in Illumina's TruSeq DNA LT adapter tube pooling guidelines.
Like the first case, we ensure that the actual list contains the entire ideal combination.
After removing the ideal adapters, we ensure that the amount of leftover Illumina TruSeq DNA LT adapters is equal to the amount of wildcards.
To represent the adapter combination fallbacks, we require a method which will attempt to match the highest possible plexity for a given list of adapters. If it cannot do this, it will attempt to match it with a lower plexity combination with a wildcard.
To achieve this, we define a recursive function that handles both the exact and wildcard cases. The ideal combination plexitys will be chosen by the patternIndex input.
If no wildcards are present, we check each combination in the designated plexity.
If a match is not found, we call the match function again. This time, we increase the amount of wildcards by 1 and reduce the plexity of the combinations by 1. The function will now compare the adapter list using the wildCardMatch function. If a match is found, the function will exit and return true.
Now, with our supporting functions defined, we can start processing our pools.
First we retrieve the definitions of the pools from the API. This node contains a list of the output pools, in addition to what input each pool contains.
Using this list, we create a map that stores the URIs of the output pools and the amount of inputs to each pool.
We then retrieve the output pools using a batchGET.
Once we have the pools, we iterate through the list.
If a pool is valid, we increment a counter which will be used in our success message.
If invalid, we set the script outcome to failure, and append to the failure message.
The script continues searching for other issues and adding their information to the failure message.
After each pool has been checked, we determine how to alert the user of the script's completion.
If a pool is invalid, an error is thrown containing the list of failures and a recommendation to review the Illumina pooling guidelines.
If all pools are valid, we alert the user of a success.
Your configuration conforms with the script's requirements, as documented in Solution.
You are running a version of Groovy that is supported by Clarity LIMS, as documented in the Clarity LIMS Technical Requirements.
The attached Groovy file is placed on the LIMS server, in the /opt/gls/clarity/customextensions folder.
GLSRestApiUtils.groovy is placed in your Groovy lib folder.
You have imported the attached Reagent XML file into your system using the Config Slicer tool.
The example code is provided for illustrative purposes only. It does not contain sufficient exception handling for use 'as is' in a production environment.
ConfirmationOfPoolComposition.groovy:
Single Indexing ReagentTypes.xml:
-i
The URI of the step that launches the script (Required)
The {stepURI:v2:http} token - in the form http://<Hostname>/api/v2/steps/<ProtocolStepLimsid>
-u
The username of the current user (Required)
The {username} token
-p
The password of the current user (Required)
The {password} token