[galaxy-dev] Bug with workflow
Hi all, I've a bug with the use of workflow. I've created my own workflow and since the latest update the workflow can be launched correctly but not completely!!! The first steps works with outputs on history, a job runs in job_working_directory for each of these steps. But for my final step : no job begin in job_working_directory so no data in history because the jobs don't exist. In my workflow the outputs are selected to be not hidden and the final step is connected with other steps. Any other one have this problem ? Thanks. Julie ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] ImportError: No module named galaxy_utils.sequence.fastq
Hello Julie, This is odd - sorry. I might be worth uninstalling and re-installing this in the tool shed admin options - in particular ensure you install tool dependencies and that this installation process succeeds. Otherwise - it might be worth trying to put some debug statements in the fastq groomer tool to try to track down the problem. Here (https://gist.github.com/jmchilton/2d61f7ab81d99a0f02fc) is a diff to have that tool write out the run-time value PYTHONPATH to Galaxy's home directory - it might be worth running a job, finding the output, setting PYTHONPATH to that value on the compute node and attempting to just import it directly. cd $HOME; python -c import galaxy.sequences.fastq Out of curiosity - what job runner are you using (local, DRMAA, etc...)? -John On Tue, Jul 1, 2014 at 4:50 AM, julie dubois dubju...@gmail.com wrote: Hi, I've this error message when I run groomer. My local instance of galaxy runs on a python virtualenv (python 2.7) and I have make the latest update with : hg pull -u. I've verified and this library is present in my galaxy-dist/lib/galaxy_utils/sequence directory. I've found no other idea than the update on this forum to run groomer correctly, any other idea ? Thanks. Julie ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] repeat tag enhancement?
Hello Jens, A high priority for the team is to replace the tool form with one that is more javascript driven - right now it repeatedly POSTs to the web server and has a lot of complicated server state handling. Moving this client side and doing these things more dynamically should enable enhancements like the ones outlined in this card (https://trello.com/c/RllVlsfg). These issues came up at the conference and they will hopefully be addressed soon-ish. This addresses the repeat tag limitations specifically - but workflows with variable numbers of input parameters isn't a problem that is just solved with UI enhancements. To broadly tackle the problem the team has been working on datasets collections and I just presented the work at the community conference bit.ly/gcc2014workflows. A lot of this is in -stable, but -central contains some important UI work and bug fixes that will be released with the next version of Galaxy. There are certainly times when it makes sense to place input dataset parameters inside of repeat blocks - but I think more tools are switching over to us multiple=true on a single data parameter input. It allows for more rapid selection of many inputs and work more seamlessly with dataset collections. Hope this helps, -John On Wed, Jul 2, 2014 at 2:03 AM, Keilwagen, Jens jens.keilwa...@jki.bund.de wrote: Hi guys, this threads has been inactive for quite a long while. However, I'd like to restart the discussion. There are two alternatives for improving the usability of the repeat tag. 1) If the repeat tag arguments could be populated using white pages and a filter similar to the possibility for workflow, the user would be able to add several inputs at once. 2) If workflows would allow for using multiple (but not fixed number of) inputs obtained via white pages as input of a repeat tag argument of a tool, the user could use the functionality of multiple inputs (white pages) in workflows. I would vote for the second proposal as it allows for building workflows with variable number of inputs (e.g. read mapping and combined SNP calling for a variable number of samples). Workflows with variable number of inputs have been brought up from time to time at several posts or meetings. Hence, solving this could be hitting 2 birds with one stone. However, proposal 2 has the drawback that using repeat tag arguments outside of workflows is still a lot of manual work. This could be circumvented by tiny workflows consisting only of the tool of interest (containing the repeat tag argument). best regards, Jens ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Galaxy/ODoSE - Output accessory orthologous genes ERROR
Dear Galaxy team, I am having a problem running Galaxy/ODoSE. In the step Extract categorize orthologs, I selected the option Output accessory orthologous genes but it didn't work and didn't output any file. The stdout contains multiple warnings: ... WARNING 15:18:06 select_taxa.select_genomes_by_ids:33 Could not find genome with BioProject ID 11 in complete genomes table WARNING 15:18:06 select_taxa.select_genomes_by_ids:33 Could not find genome with BioProject ID 10 in complete genomes table WARNING 15:18:06 select_taxa.select_genomes_by_ids:33 Could not find genome with BioProject ID 14 in complete genomes table WARNING 15:18:08 __init__.get_most_recent_gene_name:186 Could not retrieve gene name annotation based on date; returning first gene name annotation instead WARNING 15:18:08 __init__.get_most_recent_gene_name:186 Could not retrieve gene name annotation based on date; returning first gene name annotation instead WARNING 15:18:08 __init__.get_most_recent_gene_name:186 Could not retrieve gene name annotation based on date; returning first gene name annotation instead ... How can I solve this problem? Thank you in advance! Best Regards, Sérgio ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Job execution order mixed-up
To close this loop - Ilya Sytchev was experiencing this problem as well and did a bunch of tests at the recent GCC Hackathon that pretty clearly demonstrated that this problem occurs when all of the following three conditions hold - 1) Galaxy targets MySQL 2) MyISAM tables are used and 3) Galaxy runs separate web and handler processes (even with 1 and 1). Ilya's work has been documented here: https://trello.com/c/uVYR3IHc and he kindly updated the wiki to reflect these problems. The Galaxy team already strongly recommends Postgres over MySQL - but if you have to use MySQL please use InnoDB tables (the new default) instead of MyISAM. -John On Sat, Dec 7, 2013 at 9:36 AM, John Chilton chil...@msi.umn.edu wrote: Hello Yves, duplicates the history the same amount of times as the number of threadpool_workers we have configured for the job handlers Well that shouldn't be happening. Do each of these multiple histories have all of the datasets for the workflow run populated as well? I assume then that Send results to a new history are checked when running the workflow. Does this problem happen when that is not checked? I have couple of related questions - but perhaps if you could send a version of your universe_wsgi.ini to galaxy-b...@bx.psu.edu with sensitive information redacted (database passwords, id_secret, admin_users) it would answer all of them. It would be great to rule out tool related problems (though they are seeming more and more unlikely as you describe the symptoms) - can you recreate this with a big workflow that just uses standard Galaxy tools bundled with the distribution? Eitherway, if you could send us a workflow example that demonstrates the issue along with tool xml files for any custom tools that would help. Again - you can send that to galaxy-b...@bx.psu.edu if it is sensitive. Also, this workflow is being run through the GUI right - I want to rule out this being an API related problem. ... as you can probably tell I am still flummoxed. Sorry I don't have answers and thanks for your patience :(. -John On Wed, Dec 4, 2013 at 10:09 AM, Yves Gagnon yves.gag...@dnalandmarks.ca wrote: Dear Galaxy mailing list, I will be taking over this issue here now. Here is an update on this issue and our observations. I would like to know your insight on the matter if you can think of anything! We tried to revert back to a Galaxy instance running only one job handler. With that configuration, we observed that the out of order execution problem still occured, but MUCH less frequently than when using three handlers. On multiple workflow runs, only one job started while its input was not ready in only one run of the workflow. When using three job handlers, it occured on all workflow runs and on multiple jobs inside each workflow run. Our poweruser also noticed that his workflow, when taking too much time to prepare (which is always the case I think since it's a huge workflow), duplicates the history the same amount of times as the number of threadpool_workers we have configured for the job handlers. Now I am not sure both are related at all since I do not know much what is the effect of running a handler on multiple thread_workers. In any case, as of now we are staying with a single handler configuration since it in part fix the out of order execution problems, but since we have many regular users and some powerusers, that is not the ideal solution. Hope somebody can shed some light on this! Cheers! *Yves Gagnon* LIMS/ELN Developer Phone: +1 450 357-3370 Fax: +1 450 358-1154 E-Mail: yves.gag...@dnalandmarks.ca Postal Address: DNA LandMarks Inc., 84 Rue Richelieu, Saint-Jean-Sur-Richelieu, Quebec, CANADA, J3B 6X3 * DNA LandMarks - une compagnie de BASF Plant Science / a BASF Plant Science company* Confidentiality notice: The information contained in this e-mail is confidential and may be the subject of legal professional privilege. It is intended for the authorized use of the individual or entity addressed. If the receiver or reader of this message is not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is prohibited. If this email is received in error, please accept our apologies, delete all copies from your system, and notify us at supp...@dnalandmarks.ca.Confidentialité: L'information contenue dans ce courriel est confidentielle et peut être assujettie aux règles concernant le secret professionel. L'information contenue dans ce courriel est autorisée uniquement pour l'individu ou l'entité légale adressée. Si le récipiendaire ou le lecteur de ce message n'est pas celui ou celle prévue, vous êtes tenu de ne pas présenter, copier, distribuer ou utiliser le contenu de ce message. Si ce courriel est reçu par erreur, veuillez nous en excuser, veuillez détruire toutes copies de votre système nous informer à
