Filtering read by quality (20 == 99% base-calling accuracy) and length (remove very short sequences) will make the assembly cleaner and less likely to run into resource problems.
This means that the QA needs to be done on the reads used to generate the Trinity assembly and the reads mapped back against that assembly result.
This part of the error message seemed suspicious given that your reads are paired up, so I web searched and found that others ran into this problem when using the option RSEM with Bowtie. Trinity transcript_abundance.pl error using RSEM · Issue #305 · trinityrnaseq/trinityrnaseq · GitHub Some resolved it by using RSem with Bowtie2 instead. Maybe try a rerun using the Bowtie2 option? You can toggle between Bowtie and Bowtie2 in the Galaxy wrapped version of the tool.
A highly fragmented Trinity assembly could also lead to this problem (or that is my guess – if the assembled contigs do not represent full transcripts, then reads could map to different contigs and then “not match”) – but it is definitely worth a try to see if Bowtie2 works first.
You may also want to review the assembly itself, and potentially filter it by length. Any contig that is shorter than your reads will not capture hits, but contigs that are only long enough to capture one end of the read pair can lead to a multi-mapping issue.
How long should a valid contig be? It depends on the species/genome – but any “contig” that is really short (under ~100 bases, or the length of the original reads) could represent data that wasn’t incorporated into a full-length transcript. That could be related to the original read quality, untrimmed artifact, or potentially the depth or coverage of sequencing was low. Even upstream issues with how the library was prepared could be a factor.
Meaning, it is possible that full length alternatively spliced contigs (transcripts) were not generated. This could lead to mapping problems … especially if the same reads were used to generate the assembly that were later mapped back to it (a “poor” quality read would map back against itself). The goal is to create a high-quality assembly that does not include partial/duplicated content.
Please review your original assembly reads, clean those up and reassemble as needed, then try Bowtie2 with reads that also were quality filtered, to eliminate read quality and technical factors, and we can follow up from there regarding assembly content as needed.
Note: Trinity is currently problematic at usegalaxy.org, but we expect to have that resolved as a priority fix. Related Q&A about that (Trinity runs on the same cluster as these other tools): SPADES - Remote job server indicated a problem running or monitoring this job. - #10 by jennaj
Apologies for the confusion, but we can sort out the different issues, and doing more QA first is probably needed anyway.
Thanks!