BlastP frozen at start

We have tried to run a few peptide blasts in the past day, but the window seems to be frozen (remaining grey). The Blast DB that we are using was created earlier, and has been used multiple times. The peptide fasta file for the query is rather simple. Are the servers very backed up at Galaxy. Any suggestions?

Hi @tom_abrams_lab Grey means jobs are waiting. Usually this is happen when a server does not have spare resources to host jobs or many jobs were submitted by a user (many servers have limit on number of concurrent jobs). Usually Blast tools run on multiple CPUs. If it is the case, just wait. Sometimes Galaxy does not update history panel, so click at Home icon at the top menu or refresh the history. Another option: the account is over quota. in this case you should see over quota notice at the top of the history panel.
Please consider adding server tag to posts, so admins can check what is going on.
Kind regards,
Igor

Hi Igor, Thanks for your explanation and suggestions. I want to check how to identify the server details. This is running on usegalaxy.org But I don’t see info on a specific server. Can we opt to switch servers?
I just deleted some old files and tried refreshing the site. On top, it says :“using 6%” so I assume we are not at the limit.
Thanks again for your help!
Tom

Hi @tom_abrams_lab

You job looks Ok, it is just queued. The quota usage is also fine.

If that job ends up failing, it might be due to the BLAST index version. It was created with an earlier version of NCBI BLAST+ makeblastdb than you are using for BLASTp. Recreating the index would be one thing to try to resolve that.

You could even do both at the same time: 1) leave the original job queued while 2) creating a new index and starting a new blastp job using it.

Different servers use different computational resources, and at any particular time one may be “faster” that others due to chance.

It is fine to have one account at each of the public servers. The accounts are distinct and you can move data by URL between them. Indexed data is specific to the server, so copy the data the BLAST db was created from, then recreate the index per server.

Hi Jenn,
Do I understand correctly that one simply selects the server by URL, and that there are three
.Org, .Eu and .Au ?
Thanks much for all the help. We are trying a newly generated DB.

Hi @tom_abrams_lab

there are many public Galaxy servers, not just usegalaxy.*.
Select server by URL.
Data can be copied directly between Galaxy servers: click at Copy Link (chain) icon at source Galaxy, and paste the link into Upload menu > Paste/Fetch Data tab on target Galaxy.

Kind regards,
Igor

I tried going to https://galaxy.pasteur.fr
When I tried to login with my regular credentials, it failed. When I tried to create a new account, I received an error message - Please register only one account. I am confused as to how to proceed.
Does each account or each server require a different browser?

Hi @tom_abrams_lab
I just registered at Pasteur Galaxy using the same browser I use for other Galaxy servers. As I cannot reproduce the issue, it is hard to say what is going on. I don’t know if Pasteur people monitor this forum or not, so maybe email the Pasteur support (the email is on the front page). Maybe clear recent browsing history and try again. Maybe the site recorded your attempt of login and registration coming from the same IP.
Kind regards,
Igor

Thanks Igor. I will try after clearing history.
Is there a way to tell which servers are less backed up. I have attempts running more than 2 days, and still grey.
Best,
Tom

Hi @tom_abrams_lab
The main Galaxy server is in huge demand. They are very popular.
Galaxy Europe provides links to status of the server (in fact, uptime for usegalaxy.*, training site and some other services), as well as statistics, with various metrics including queued jobs.
Galaxy Australia provides live update on active and queued jobs.
Servers might have different setup, such as limit on number of concurrent jobs for some tools, so some jobs may wait in queue while jobs with minimal resource requirements might be submitted for execution, so the server load might not give the whole picture. Jenn said your jobs are fine.
Kind regards,
Igor