I am trying to align my fastqsanger.gz files with HISAT2 but it is not working. The problem arose after I had successfully ran an initial set of samples for DEGs, using HISAT2 as part of it. Now that I uploaded the rest of my files, the concatenated fastqsanger.gz files will not go through HISAT2. I even try running my previously successful files with no avail, which makes me think it is in fact a HISAT2 or galaxy issue. Can anyone help? Thanks in advance!
1 Like
Hi @japiz
Try one more rerun now. We’ve had reported issues of mapping jobs failing but that was unreproducible in tests and others have had success today.
If your rerun today fails, please send me a direct message with a share link to your history, a link to this post, and note which dataset is the problem.
More details about the prior reported problems, how to send a direct message, and how to generate a share link are in this post: bowtie2 not working
Thanks!
Hi @jennaj,
Thanks for getting back to me. The problem still persists today. I’d be happy to send you the info, but I couldn’t find how to send you a direct message. I didn’t see an envelope when clicking on your “@” and couldn’t start a new direct message from my Account>>Messages section either. Maybe I’m missing something? Thanks again for your help.
Best,
J. Apiz
1 Like
Ah, Discourse (how this site is run) updated the UI a bit. Try this:
Bug reporting directly through the usegalaxy.org web interface is still problematic, or we could use that instead … so, that’s why we are using share links/direct messages. I’m curious about a potential cluster/job server-side issue.
For some reason I seem to be missing the new message button all together. Tried in two different browsers. Perhaps replying to a direct message from you might be a temporary way around this.
Best,
J. Apiz
1 Like
Odd. It may be a setting I can adjust.
Meanwhile, I just sent you a direct message.
Plus, I am rerunning HISAT2 tests against all 3 clusters. Twice each. Will take some time to complete.
Ok, I found the problem and was able to reproduce it.
The “Jetstream” cluster is the problem.
Near the bottom of the tool form is an option to select the cluster to run the job on. You were using the default, which means Galaxy decides where to send the job. It will never send a mapping job to Stampede (and expect mapping jobs to fail there anyway, for a different reason). Galaxy will send mapping jobs to Jetstream – and since that is problematic, there is a way to avoid it.
Set up your tool form like this:
You’ll see this option first:
In the pull-down menu switch to “Specify job resource parameters” and then select the “Galaxy Cluster (default)” option:
I will alert our admin about this. More feedback soon. Meanwhile, this will allow you to get your jobs to run successfully.
Thanks for taking the time to follow through and share your history, much appreciated!
Update: Ticket for the issue is now here https://github.com/galaxyproject/usegalaxy-playbook/issues/257
I’m glad to say this did fix my issue!
Initially I was hesitant, as upon changing the Job Resources Parameters setting to the Specify Job Resource Parameters option, the Galaxy cluster (default) option was already preset under Computer Resource. If I understood correctly,the reason this makes sense is because when leaving the default Use default job resource parameters option in Job Resource Parameters, Galaxy will use the Jetstream cluster, while changing to Specify Job Resource Parameters will in turn use the Galaxy Cluster option as default, successfully redirecting the job to a different cluster.
Thanks for your help @jennaj !
1 Like
Super, glad it worked.
And yes, you are interpreting the cluster selections correctly.
Using all defaults == Galaxy decides which cluster to send the job to. Factors are based on the tool itself, cluster load distributions, and the like. In short, get the job executed on the most appropriate cluster(s) as resources are available.
Specifically sending to the “Galaxy cluster (default”) == means that there is no “Galaxy” decision making based on the tool itself or cluster/load related factors. It is definitely possible to pick a cluster that will “not work” – and for mapping and other tools that use indexed genomes, Stampede is not appropriate. Both “(beta)” clusters should never be used by most people. Galaxy will never send jobs to an inappropriate cluster, but people can, by manipulating this setting.
There isn’t a good way to clarify all of this in the user interface, although we made an attempt at it in this FAQ: https://galaxyproject.org/main/. However, that can also be difficult to interpret.
So, glad you wrote in, we isolated the problem, and now have a successful workaround. When the ticket closes (when using “Default-let-galaxy-choose-the-cluster” or specifying “Jetstream” both work), I’ll post back to this thread and the other.
Then all can decide what you want to do. Jetstream is a larger cluster resource and jobs will often “run faster there” (same execution time, but shorter queue time) but not always. Letting “Galaxy decide” is generally best, and that is why it is the “default” on the tool form… but that is not an option until the Jetstream issues are resolved for this problem. Resolution should be soon but I cannot offer any accurate estimates, yet. 
I appreciate that you took the time to write back AND explain your confusion. Usage confusion is important feedback, thank you!