This error in the stderr logs means that the job is running for longer than the maximum execution time the public service can provide. There could be an input problem that you can fix – or the data really is too large to assemble at the public resource.
There are no known server issues with this tool. A test was just completed successfully yesterday for this exact same tool at this exact same server – after a similar report from another end-user (perhaps even you?).
-
FAQ: Galaxy Support - Galaxy Community Hub >> My job ended with an error. What can I do? >> Job and Tool Error Help - Galaxy Community Hub && Job and Tool Error Help - Galaxy Community Hub
-
Galaxy Help prior Q&A: Search results for 'assembly' - Galaxy Community Help >> Example: de novo assembly using Trinity in Galaxy
-
Troubleshooting summary (how-to covered in more details in the Q&A above). You’ve already done some of it, but this is the reference for everyone.
- Try at least one rerun to eliminate server/cluster factors.
- Trinity requires both ends of a read when assembling pairs. Double-check if that is true for your read inputs.
- Do some more QA/QC on your reads (tools: FastQC > Trimmomatic > FastQC > MultiQC). Bonus here is that
Trimmomaticwill sort your reads into paired vs not-paired after QA outputs. - Consider downsampling your reads. (tool: Seqtk)
-
If the job remains too large to execute at the public server after making adjustments, setting up your own server with more resources is less complicated than many realize – and non-technical researchers around the world choose that way to use Galaxy every day for ongoing, large, or time-sensitive projects, or to simply have more flexibility. You can certainly still have an account on the public server to publish data publically, etc, even when running your own private server for routine work.
- Ways to use Galaxy: https://galaxyproject.org >> Use
- The GVL version of Cloudman is one choice and AWS offers grants. AWS Programs for Research and Education
Thanks!