trinity from HISAT2 unaligned reads

[Pedro]

Hi,

I am trying to run trinity on unaligned reads files generated by HISAT2.

I have tried the following, after consulting other users quaries:

1. directly with the files generated by HISAT2
2. after FASTQgroomer with default parameters
3. after Trimmomatic to use only reads with pairs
4. after intelacer and de-interlacer

Trinity never start immediately, staying in grey until the next day, when I always get the same error message: Fatal error: Exit code 1 ()

Any clue?

Many thanks

[jennaj]

Hi @Pedro

@Pedro

Trinity never start immediately, staying in grey until the next day,

This just means the job queued. That is normal and expected. See → Understanding job statuses

@Pedro

when I always get the same error message: Fatal error: Exit code 1 ()

This is just a top level error shown inside the dataset. The rest of the job logs will likely have more informative messages, and the kinds of input/parameter details others will need to help you more. This is how and where to find them → Troubleshooting errors

That said, if the reads didn’t map to a reference genome that is a strong clue that the data is not from that species. It could be contamination or even low quality data of some type. Meaning, those reads may not assemble for the same reasons that they didn’t map.

Maybe try to find out what those reads are? The QA steps might have revealed something, so start with the FastQC reports.

Other ideas

@jennaj

Assembly and annotation processes are super sensitive to data content. So, you could try mapping the assembly against a reference (same species, or different) and reviewing in a browser like IGV, along with any known annotation (GTFs) and explore that way too. You could even just BLAT or BLAST+ a few sequences or any suspect sequences at UCSC or NCBI to see what happens. None of that is exact, it is exploratory.

---

---

Give those a review first. I’m not clear on why you were assembling to start with, so please explain that part if you need more help.

[Pedro]

Hi,
Thanks for your answer.
I am working with SRA data from NCBI. I am looking at not mapped reads as I did before using galaxy tools, including trinity version 2.9.1 to identify viruses in the reads (you may see Vidal-Quist et al. 2021 10.1111/all.14884). In this regard, yesterday, I ran trinity again using the same sample files that failed giving always the general error, but this time I change the trinity version to v2.9.1. The program is now working and I getting trinity assemblies without errors (for the ones that ended). Why a former version is working and not the current one? May it be related to something “wrong” in the latest version? perhaps related to the recognition of the format of the files generated by HISAT2?

Many thanks,

[jennaj]

@Pedro

Why a former version is working and not the current one? May it be related to something “wrong” in the latest version? perhaps related to the recognition of the format of the files generated by HISAT2?

Hi @Pedro

Other people have had assembly success with prior versions as well. Not everyone, just some people. We haven’t been able to identify a technical reason for the difference (what we can address on the Galaxy side). It may be that the newer version is “picker” about the read content in some way intrinsic to the algorithm – but that is just my guess from the reports of issues here over the last few months. This isn’t completely closed out for us yet so more may be found out later on.

Anyway, glad that you found a version that assembles your data! Thanks for explaining what you were doing e.g. filtering read species by mapping. That totally makes sense

[Pedro]

Thanks for all your attention and quick response