Hello all,
I've written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with "$ mb" and then enter your commands, or directly execute a Nexus file (containing the data and commands) with " $ mb <nexusfilename>".
Please correct me if I'm missing something or thinking about this completely wrong. I'd appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca mailto:ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
Ann,
I think you may be able to do this by generating another nexus file using "configfiles" in the Galaxy tool config which just contains a command block, similar to the example here:
http://mrbayes.sourceforge.net/wiki/index.php/FAQ#How_do_I_run_MrBayes_in_ba...
-- jt
On Mon, Oct 29, 2012 at 1:24 PM, Gomez, Ann Ann.Gomez@agr.gc.ca wrote:
Hello all,
I’ve written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with “$ mb” and then enter your commands, or directly execute a Nexus file (containing the data and commands) with “ $ mb <nexusfilename>”.
Please correct me if I’m missing something or thinking about this completely wrong. I’d appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
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:
Brilliant, thanks! I had seen the FAQ, but didn't know about configfiles. Much appreciated!
Ann
-----Original Message----- From: james@taylorlab.org [mailto:james@taylorlab.org] On Behalf Of James Taylor Sent: Monday, October 29, 2012 2:03 PM To: Gomez, Ann Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] MrBayes wrapper - set parameters through Galaxy?
Ann,
I think you may be able to do this by generating another nexus file using "configfiles" in the Galaxy tool config which just contains a command block, similar to the example here:
http://mrbayes.sourceforge.net/wiki/index.php/FAQ#How_do_I_run_MrBayes_in_ba...
-- jt
On Mon, Oct 29, 2012 at 1:24 PM, Gomez, Ann Ann.Gomez@agr.gc.ca wrote:
Hello all,
I've written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with "$ mb" and then enter your commands, or directly execute a Nexus file (containing the data and commands) with " $ mb <nexusfilename>".
Please correct me if I'm missing something or thinking about this completely wrong. I'd appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
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:
Ann, Also to your request "I'd appreciate any input about MrBayes or a similar kind of tool."
We are developing a suite of tools for phylogenetics in Galaxy. We are calling the tool suite Osiris.
We are currently adding the full tool suite to Bit Bucket: https://bitbucket.org/repo/all?name=osiris_phylogenetics
and many tools are on the tool shed under a repository called ucsb_phylogenetics.
We are describing some of the tools here:
http://osiris-phylogenetics.blogspot.com/
We are in rather active development right now, but the RAxML tools have been used rather extensively, and allow some interactive choices (model choice, bootstrap reps, DNA v Protein, etc). We also have a tool for BEAST (very simple, just passes the formatted xml file to run the program through Galaxy). Another phylogenetic tree estimation tool on the tool shed (not ours) exists for GARLI.
We plan to develop a tool for MrBayes, as well, but perhaps we will not have to anymore!
Best wishes,
Todd Oakley
On 10/29/2012 11:43 AM, Gomez, Ann wrote:
Brilliant, thanks! I had seen the FAQ, but didn't know about configfiles. Much appreciated!
Ann
-----Original Message----- From: james@taylorlab.org [mailto:james@taylorlab.org] On Behalf Of James Taylor Sent: Monday, October 29, 2012 2:03 PM To: Gomez, Ann Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] MrBayes wrapper - set parameters through Galaxy?
Ann,
I think you may be able to do this by generating another nexus file using "configfiles" in the Galaxy tool config which just contains a command block, similar to the example here:
http://mrbayes.sourceforge.net/wiki/index.php/FAQ#How_do_I_run_MrBayes_in_ba...
-- jt
On Mon, Oct 29, 2012 at 1:24 PM, Gomez, Ann Ann.Gomez@agr.gc.ca wrote:
Hello all,
I've written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with "$ mb" and then enter your commands, or directly execute a Nexus file (containing the data and commands) with " $ mb <nexusfilename>".
Please correct me if I'm missing something or thinking about this completely wrong. I'd appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
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:
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:
On Oct 29, 2012, at 3:20 PM, Todd Oakley todd.oakley@lifesci.ucsb.edu wrote:
Ann, Also to your request "I'd appreciate any input about MrBayes or a similar kind of tool."
We are developing a suite of tools for phylogenetics in Galaxy. We are calling the tool suite Osiris.
We are currently adding the full tool suite to Bit Bucket: https://bitbucket.org/repo/all?name=osiris_phylogenetics
and many tools are on the tool shed under a repository called ucsb_phylogenetics.
We are describing some of the tools here: http://osiris-phylogenetics.blogspot.com/
We are in rather active development right now, but the RAxML tools have been used rather extensively, and allow some interactive choices (model choice, bootstrap reps, DNA v Protein, etc). We also have a tool for BEAST (very simple, just passes the formatted xml file to run the program through Galaxy). Another phylogenetic tree estimation tool on the tool shed (not ours) exists for GARLI.
We plan to develop a tool for MrBayes, as well, but perhaps we will not have to anymore!
Best wishes,
Todd Oakley
This is an interesting project. I'm glad to see more people working on phylogenetics related wrappers and workflows. I wonder if we could get a "Phylogenetics" category added to the main Galaxy Toolshed, so we could put all the relevant wrappers in there to make them easier to find considering the apparent duplication of efforts.
Regards,
Alex
On Oct 29, 2012, at 4:40 PM, Oleksandr Moskalenko om@hpc.ufl.edu wrote:
This is an interesting project. I'm glad to see more people working on phylogenetics related wrappers and workflows. I wonder if we could get a "Phylogenetics" category added to the main Galaxy Toolshed, so we could put all the relevant wrappers in there to make them easier to find considering the apparent duplication of efforts.
Good idea, the main toolshed now has a Phylogenetics category.
-Dannon
Thanks Dannon for adding the Phylogenetics category, I changed the name of this thread, to go in a related by new direction:
I wonder if the Galaxy developers and community have any opinions on what is the best way to organize tools into repositories. We've developed a large number of tools to allow my lab to conduct phylogenetic analyses in Galaxy. Inspired by the mothur package in Galaxy, which is all in one repo, I made the decision to add all our related tools to 1 repo on the tool shed. However, it seems that makes individual tools like raxml difficult to find for other users. Recently, we started putting these tools on to bitbucket, and organizing them in different categories (alignment, phylogenetics, orthologies, etc), which is a compromise between all-in-one-repo and each-its-own-repo.
The thing is that many of the tools do not stand alone, and really are designed to function with other tools in the package. Any philosophies or opinions are welcome, as I feel like I have not come to a good solution on this...
Todd
On 10/29/2012 1:50 PM, Dannon Baker wrote:
On Oct 29, 2012, at 4:40 PM, Oleksandr Moskalenko om@hpc.ufl.edu wrote:
This is an interesting project. I'm glad to see more people working on phylogenetics related wrappers and workflows. I wonder if we could get a "Phylogenetics" category added to the main Galaxy Toolshed, so we could put all the relevant wrappers in there to make them easier to find considering the apparent duplication of efforts.
Good idea, the main toolshed now has a Phylogenetics category.
-Dannon ___________________________________________________________ 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:
On Mon, Oct 29, 2012 at 9:23 PM, Todd Oakley todd.oakley@lifesci.ucsb.edu wrote:
We've developed a large number of tools to allow my lab to conduct phylogenetic analyses in Galaxy. Inspired by the mothur package in Galaxy, which is all in one repo, I made the decision to add all our related tools to 1 repo on the tool shed. However, it seems that makes individual tools like raxml difficult to find for other users.
Todd, I prefer bundling related tools (and other assets) in repositories.
If the problem is discovery perhaps we can fix this in the toolshed UI by adding the ability to browse for tools directly in addition to browsing for repositories?
James, Yes, I think discovery is the main problem, and your suggestion would help. I suppose having conventions would also help discovery and understanding in general, but that is difficult to achieve in a community-based project. Todd
On 10/30/2012 8:00 AM, James Taylor wrote:
On Mon, Oct 29, 2012 at 9:23 PM, Todd Oakley todd.oakley@lifesci.ucsb.edu wrote:
We've developed a large number of tools to allow my lab to conduct phylogenetic analyses in Galaxy. Inspired by the mothur package in Galaxy, which is all in one repo, I made the decision to add all our related tools to 1 repo on the tool shed. However, it seems that makes individual tools like raxml difficult to find for other users.
Todd, I prefer bundling related tools (and other assets) in repositories.
If the problem is discovery perhaps we can fix this in the toolshed UI by adding the ability to browse for tools directly in addition to browsing for repositories? ___________________________________________________________ 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:
On Oct 29, 2012, at 9:23 PM, Todd Oakley wrote:
I changed the name of this thread, to go in a related by new direction:
I wonder if the Galaxy developers and community have any opinions on what is the best way to organize tools into repositories. We've developed a large number of tools to allow my lab to conduct phylogenetic analyses in Galaxy. Inspired by the mothur package in Galaxy, which is all in one repo, I made the decision to add all our related tools to 1 repo on the tool shed. However, it seems that makes individual tools like raxml difficult to find for other users. Recently, we started putting these tools on to bitbucket, and organizing them in different categories (alignment, phylogenetics, orthologies, etc), which is a compromise between all-in-one-repo and each-its-own-repo.
The thing is that many of the tools do not stand alone, and really are designed to function with other tools in the package. Any philosophies or opinions are welcome, as I feel like I have not come to a good solution on this...
Todd
I've added the following tool shed wiki page to provide discussion points related to this question.
http://wiki.galaxyproject.org/AToolOrASuitePerRepository
Here are the current contents of the page:
A single tool or a suite of tools per repository Many tool developers in the Galaxy community question the best way to organize tools in their tool shed repositories. Some groups have developed a large number of tools to allow their labs to perform analyses in Galaxy and took the approach of including all related tools in a single repository in the tool shed. Others have chosen to restrict each repository to include a single tool. What is the "best practice"?
Both approaches are ok, but here are some points to consider when making this decision. Notice that these points are valid at the time this page was written, so this discussion will evolve as new tool shed features and Galaxy-related tool shed features are introduced and mature over time.
The benefits of a single tool per repository
Restricting a repository to include a single tool provides more flexibility to Galaxy administrators to install only those specific tools in which their users have interest. Sometimes installing a suite of tools in order to get only one or two of them is not optimal. Some time in the future, Galaxy workflows may provide the ability to search for tools defined in the workflow that are not available in the Galaxy instance. Ideally the Galaxy administrator will be able to locate and install only the precise list of missing tools in order to enable the workflow to run. For example, assume a user imported a workflow into their local Galaxy instance that was developed by someone else in a different Galaxy instance. The Galaxy workflow UI may provide a feature that searches available tool sheds for the tools required by the imported workflow that are not available in the Galaxy instance. Restricting repository contents to single tools would enable installation of only those missing tools required by the workflow. Tool shed repository that include tools have certain mercurial change set revisions that are installable into a local Galaxy instance. These revisions are defined by the versions of the tools included in the repository. Repositories that are restricted to contain a single tool will ensure that a new revision installation will be required only when that tool version changes. Repositories that include multiple tools require a new installation revision when the version of any one of the tools changes, possibly resulting in multiple versions of the same tool installed into a single Galaxy instance. Of course, Galaxy will load only a single instance of a tool version into the tool panel, but the tool and related files will still be installed on disk multiple times. The weaknesses of a single tool per repository
With current tool shed features, if multiple tools share required third-party dependencies and you design your repository to install them when the repository is installed into a Galaxy instance (by including a file named tool_dependencies.xml in your repository), restricting a repository to a single tool will force you to include the same tool_dependencies.xml file in each repository whose contained tool requires the same dependency. This will also install and compile the same dependencies separately for each repository when it is installed into a Galaxy instance. In the near future, the tool shed will include a new feature that we are calling cross-repository dependencies which will eliminate this weakness. This feature will provide a means of defining a repository as a dependency for another repository. For example, the current emboss_datatypes repository in the main Galaxy tool shed will be defined as a dependency for the current emboss_5 repository in the same tool shed. So when the emboss_5 repository is installed, the emboss_datatypes repository will be automatically installed along with it. If tools are not intended to provide meaningful analyses on their own, but are designed to function with other tools, restricting a repository to a single tool will require a Galaxy administrator to install multiple repositories in order to provide all necessary tools to their users.
The benefits of a suite of tools per repository
With current tool shed features, if multiple tools share required third-party dependencies and you design your repository to install them when the repository is installed into a Galaxy instance (by including a file named tool_dependencies.xml in your repository), then all tools included in the repository can share the same third-party dependency, ensuring that the dependency only needs to be installed and compiled once for multiple tools. This benefit will be eliminated in the near future with the planned introduction of the cross-repository dependencies feature described above. In some cases multiple tools are not intended to provide meaningful analyses on their own, but are designed to function with other tools in the suite. In these cases, it makes sense for all tools to be installed into a Galaxy instance, and thus, the tools may all be included in a single repository. In the near future, the tool shed will include a new feature that we are calling cross-repository dependencies (see above). This feature will enable a repository to be defined as a "tool suite" of sorts, where the repository includes only atool_dependencies.xml file that defines multiple separate repositories that should be installed. Each of these repositories could contain a single tool, allowing a Galaxy administrator to install each tool separately. If the administrator chooses to install the "tool suite" repository, each separate repository would be automatically installed, providing the entire suite of tools with the single installation. This new feature could ultimately eliminate the benefits of including a suite of tools in a single repository since, as discussed above, it will eliminate the issue of having to install and compile the same version of a tool dependency for each dependent tool in separate repositories. The weaknesses of a suite of tools per repository
Sometimes installing a suite of tools in order to get only one or two of them is not optimal. Restricting a repository to include a single tool provides more flexibility to Galaxy administrators to install only those specific tools in which their users have interest. Including multiple tools in a single repository may make individual tools more difficult to find with the current tool shed features. Although it is currently possible to search for specific tools by partial or complete tool names and descriptions, the ability to browse for tools in the tool shed directly in addition to browsing for repositories is planned for the near future.
Hi Ann,
Configfiles is the way to go. I have writtent the BEAST (and TreeAnnotator), Garli, and RAxML wrappers that are all available in the Galaxy ToolShed. BEAST uses an input xml file that it can parse to execute the analysis. Garli can take a config file that's generated by the Galaxy from the options a user selects in the interface. RAxML is a more traditional command-line application albeit with very convoluted combinations of inputs and outputs that change on every release, which is why my wrapper only supports RAxML 7.3.2. Galaxy provides a lot of choices for handling the applications inputs. MrBayes in this regard is most similar to Garli, so you can take a look at that wrapper. You can take the options from the Galaxy mrbayes interface and write them to a config file that can be fed to MrBayes as a separate NEXUS file just as the Chapter 5 "How do I run MrBayes in batch mode?" of the MrBayes manual describes.
Regards,
Alex
On Oct 29, 2012, at 2:03 PM, James Taylor james@jamestaylor.org wrote:
Ann,
I think you may be able to do this by generating another nexus file using "configfiles" in the Galaxy tool config which just contains a command block, similar to the example here:
http://mrbayes.sourceforge.net/wiki/index.php/FAQ#How_do_I_run_MrBayes_in_ba...
-- jt
On Mon, Oct 29, 2012 at 1:24 PM, Gomez, Ann Ann.Gomez@agr.gc.ca wrote:
Hello all,
I’ve written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with “$ mb” and then enter your commands, or directly execute a Nexus file (containing the data and commands) with “ $ mb <nexusfilename>”.
Please correct me if I’m missing something or thinking about this completely wrong. I’d appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
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:
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:
Hi Alex, Todd; thanks for the info and links! The Garli tool looks a lot more sophisticated than what I have so far, so I'm sure it will be helpful to look at.
Ann
-----Original Message----- From: Oleksandr Moskalenko [mailto:om@hpc.ufl.edu] Sent: Monday, October 29, 2012 4:26 PM To: Gomez, Ann Cc: galaxy-dev@lists.bx.psu.edu List Subject: Re: [galaxy-dev] MrBayes wrapper - set parameters through Galaxy?
Hi Ann,
Configfiles is the way to go. I have writtent the BEAST (and TreeAnnotator), Garli, and RAxML wrappers that are all available in the Galaxy ToolShed. BEAST uses an input xml file that it can parse to execute the analysis. Garli can take a config file that's generated by the Galaxy from the options a user selects in the interface. RAxML is a more traditional command-line application albeit with very convoluted combinations of inputs and outputs that change on every release, which is why my wrapper only supports RAxML 7.3.2. Galaxy provides a lot of choices for handling the applications inputs. MrBayes in this regard is most similar to Garli, so you can take a look at that wrapper. You can take the options from the Galaxy mrbayes interface and write them to a config file that can be fed to MrBayes as a separate NEXUS file just as the Chapter 5 "How do I run MrBayes in batch mode?" of the MrBayes manual describes.
Regards,
Alex
On Oct 29, 2012, at 2:03 PM, James Taylor james@jamestaylor.org wrote:
Ann,
I think you may be able to do this by generating another nexus file using "configfiles" in the Galaxy tool config which just contains a command block, similar to the example here:
http://mrbayes.sourceforge.net/wiki/index.php/FAQ#How_do_I_run_MrBayes _in_batch_mode.3F
-- jt
On Mon, Oct 29, 2012 at 1:24 PM, Gomez, Ann Ann.Gomez@agr.gc.ca wrote:
Hello all,
I've written a MrBayes wrapper that accepts a Nexus file (presumably containing a data block and a command block). In order to make it a bit easier for new users, I was hoping to be able to let users specify some parameters, such as their model, in Galaxy, as opposed to including it in the command block of the Nexus file. Am I correct in thinking this is not possible since MrBayes does not have a way to invoke commands in-line?
To clarify for non-MrBayes people, my limited understanding is that you either invoke the interpreter with "$ mb" and then enter your commands, or directly execute a Nexus file (containing the data and commands) with " $ mb <nexusfilename>".
Please correct me if I'm missing something or thinking about this completely wrong. I'd appreciate any input about MrBayes or a similar kind of tool.
Cheers,
Ann
Ann Gomez
Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada
KW Neatby Bldg | éd. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: ann.gomez@agr.gc.ca Telephone | Téléphone 613-759-6805 Facsimile | Télécopieur 613-759-1701 Government of Canada | Gouvernement du Canada
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:
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:
galaxy-dev@lists.galaxyproject.org
-
Dannon Baker -
Gomez, Ann -
Greg Von Kuster -
James Taylor -
James Taylor -
Oleksandr Moskalenko -
Todd Oakley