HISAT2 on Cutadapt output

1

Hi All,

I trimmed my paired datasets for adapters using Cutadapt. However, the output of the Cutadapt is not visible if I want to run HISAT2 subsequently. RNA STAR can easily use detect Cutadapt datasets for further processing. I can circumvent this problem by generating a new list of dataset pairs, but I assume there must be a faster way, because, when building a new list of dataset pairs, I also need to edit the pair name in order to keep a better overview further down the pipeline. Am I overlooking something?

1 Like
2

Hey Henk,
Probably HISAT2 has a problem to realize that your data is valid as an input. Please check that the data output of Cutadapt is in a fasta/fastq format and please also check if the data is not marked as hidden in Galaxy.

1 Like
3

Hi F,

Thanks for your quick reply. The files are of fastqsanger.gz type and I was able to get the trimmed database visible for further analyses when I unhide them. Unfortunately, I do need to edit the attributes in order to keep better track of the individual pairs for downstream applications. Perhaps I do still overlook something or is this indeed a little flaw in a, for the rest, pleasant platform to work on.

Henk

1 Like
4

Update 4/22/21

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).

History: https://usegalaxy.org/u/jen-galaxyproject/h/copy-of-test-cutadapt-listpaired--hisat2

Workflow: Galaxy

Hi @Henk

The data is in a paired-end dataset collection with the datasets inside it assigned the datatype fastqsanger.gz, correct? The output from CutAdapt?

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.

hisat2-paired-collection-input
hisat2-paired-collection-input1914Ă—286 25.1 KB

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).

Few questions:

  1. 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.

  2. 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.

Thanks!