I am running a MAG analysis workflow on Galaxy Europe and I currently have several GTDB-Tk Classify genomes jobs that have remained in queued state for several days.
I am using:
Galaxy Europe (usegalaxy.eu)
GTDB-Tk Classify genomes
Tool version: 2.6.1+galaxy0
Input: collections of MAG bins generated with MetaBAT2
The previous steps of the workflow (assembly, mapping, MetaBAT2, CheckM and CheckM2) complete normally. Some GTDB-Tk jobs have eventually completed, but many others remain queued without starting, and I still have a large number of samples to analyse.
For the queued jobs:
Job State: queued
Standard Output: empty
Standard Error: empty
No exit code is generated, so the jobs do not appear to have started.
Could you please confirm whether there is currently a GTDB-Tk resource/queue backlog on Galaxy Europe?
I would also like to know whether you recommend simply leaving these jobs queued, or whether there is currently another recommended way to run GTDB-Tk for a large number of MAG samples.
I provide Job API ID as a example:
Job API ID
4838ba20a6d86765e8a3219f2ce61362
and can provide history links or workflow invocation links if needed.
There were some server changes that may explain your queue behavior.
I would leave the jobs queued unless the administrators state that a rerun is needed. They will usually be able to get the existing backlog of queue jobs to process. But let’s see what they recommend this time.
RIght now, I see about 400 queued with about 10-12 running at any particular time. How long this current queued group will take to process is difficult to predict since the read content, not just the file sizes, has an impact on runtime. It is more than it was a few weeks ago which may reflect some of the other issues on the server or it could just be more people coming back from summer break and starting new projects!
I would leave it in the queue. We are experiencing a general high volume of jobs.
Your tool in specific, according to our rules, require 200GB of memory to run. This is a lot of resources and it will take some time to find a slot within our scheduler.
