Understanding the Velvet configuration
We will now explain how the configuration that we made actually works. And hopefully this will make it possible for you to design your own integrations.Going back to figure 8.10, there is a text field at the top. This is where the command expression is created, in this case:
/opt/local/velvet/clcbio/velvet.sh {hash size} {read type}
{reads} {expected coverage} {contigs}
The first is the path to the script, and the following are parameters that are interpreted by the server when calling the script because they are surrounded by curly brackets { }. Note that each parameter entered in curly brackets gets an entry in the panel below the command line expression.
The first one, hash size, can be entered as a Double (which is a number in computer parlance) and it is thus up to the user to provide a value. A default value is entered here in the configuration (31).
The second one is the read type which has been configured as a CSV enum which is basically a list. The first part consists of the parameters to be used when calling the script (-short, -shortPaired, -long, -longPaired), and the second part is the more human-readable representation that is shown in the Workbench (Short, Short Paired, Long, Long Paired).
The third parameter is reads which is the input data. When the User-selected input data option is chosen, a list of all the available export formats is presented. In this case, Velvet expects a fasta file. When a user starts Velvet from the Workbench, the server starts exporting the selected input data to a temporary fasta file before running the script.
The expected coverage is similar to hash size.
The last parameter is contigs which represents the output file. This time, a list of import data formats is available used to import the data back into the folder that the user selected as save destination.