Re-tested with the prior test, plus created a new extracted workflow and reran that. Everything is working.
I had forgotten that
Cutadapt will split a paired-end collection into two collections: one contains the forward reads, and one contains the reverse reads. Maybe this is the problem you had? And this example usage will help you to sort out the problems you were having? The end result from
HISAT2 is a single collection.
The data is a bit large in the history, but you don’t need to actually import it – use the “view” function, all the details are available.
The workflow is very simple and doesn’t consume any extra quota space, so importing and perhaps using it or reviewing it in the editor will help even more. You’ll see that a single collection of paired-end reads was input to
Cutadapt, then resulting collections of the forward and reverse reads were input to
HISAT2, producing one final collection of mapped BAMs (one per pair).
Workflow: Galaxy | Accessible Workflow | Workflow constructed from history 'Copy of 'test cutadapt listpaired' + hisat2'
The data is in a paired-end dataset collection with the datasets inside it assigned the datatype
fastqsanger.gz, correct? The output from
HISAT2 should be able to recognize that dataset collection and process it directly.
The collection should be in the active history, with this option set on the
HISAT2 tool form. Note: The screenshot is from loading the tool with a new, empty history that does not contain inputs of the proper datatype. It is a good way of discovering what the appropriate/recognized inputs are. When you run this, the input should be populated with one or more paired collections assigned one of those specified datatypes. Compressed will be recognized and uncompressed automatically as part of the pre-processing.
If you do not get a result like that, something is going wrong, and we can follow up on that. Rebuilding the collection or unhiding collection elements should not be needed (although they both are valid workarounds for this problem!). Let’s try to fix it at the source.
Cutadapt had some issues with Workflows in the past – but am pretty sure those are resolved now (most current Galaxy release + most current tool version).
Where are you using Galaxy? URL if a public server. And are you using the most current tool versions available there? We can follow up from there – an example might be good to review (directly, not publically) – if needed, we’ll explain how.
If you own Galaxy (local, cloud), are you upgraded to the latest Galaxy version? Are the tools updated from the ToolShed? Has this worked before or it is a new problem? If using a Workflow, did this stop working after changes (not necessarily these steps)? You might even want to check to see if some sample of this works at one or any of the UseGalaxy.* servers (as a comparison).
Let’s start there. This was an issue before, so seems odd to have it come up again. I’ll also review/rerun our prior test cases at UseGalaxy.org and will write back with that result.