Thanks, Bob, for your reply and also for pointing to the correct chapters in the lastz-readme! Having said that, it's great to hear the wrapper is scheduled to be extended/improved.

It's not clear whether the wrapper would be better if it allowed each scoring option to be set as a separate field, or if they were incorporated in a file, or if (somehow) they were one of your galaxy history items. Do you have any thoughts on that?

I'm a bit curious. On the one hand, it'd be truely convenient to have all arguments specified just by submitting a "lastz-config"- history-item to the wrapper. On the other hand, I assume most galaxy users are sticking to YASRA-modes and only those with special needs would go for custom-configs. I, for example, will have to include lastz-mapping in a workflow and will save my desired lastz-config within the according workflow item. In this regard, it wouldn't be too nice, if I had to have a config-file handy (anyone else willing to execute this workflow would need the config file as well, right?!). Thanks again! Uwe -----Ursprüngliche Nachricht----- Von: Bob Harris [mailto:rsharris@bx.psu.edu] Gesendet: Montag, 6. Juni 2011 18:06 An: Appelt, Uwe Cc: galaxy-user@lists.bx.psu.edu Betreff: Re: [galaxy-user] LASTZ arguments in "Full parameter list"-mode Howdy, Uwe, (I don't speak for the galaxy group, but I watch the list for lastz- related messages.)

Is it possible to specify more arguments in "Full parameter list"- mode, particularly those that're implicitely described in YASRA-mode (match/mismatch rewards and step-size (Z/step))?

As you indicate, the galaxy wrapper for lastz only provides access to certain combinations of arguments. At present, the only ways I know that you would be able to access other lastz parameters would be either to (1) write your own custom galaxy wrapper or (2) install lastz and run it from the command line. Kelly Vincent is planning to update the galaxy wrapper some time this summer, so this is something she's likely to address with that update.

However, heading to "Full parameter list"-mode leads to excessive CPU-use, because (presumably) the step-size (default=1?) is left unset.

You are correct that the default step is 1. (defaults are shown at the bottom of each command section in the lastz readme file which can be found at www.bx.psu.edu/~rsharris/lastz or at the Miller Lab website) Depending on your data, a step of 1 may be overly sensitive causing lastz to spend a more time than necessary.

Also, it'd be great to be able to alter not only gap penalties, but match/mismatch rewards as well. (Obviously a mismatch would cause the same problem).

Ideally I think the wrapper interface should allow you to point at a lastz scoring file, which can contain all the scoring parameters. This is an oversight-- the thinking when the wrapper was written was that the yasra settings would be sufficient (and work well) and would simplify the user's choices, making it more likely that the user would choose settings appropriate for their data. I've discussed this with Kelly some, this morning. It's not clear whether the wrapper would be better if it allowed each scoring option to be set as a separate field, or if they were incorporated in a file, or if (somehow) they were one of your galaxy history items. Do you have any thoughts on that?

I'm dealing with 454 reads and it's crucial to the scenario to have the 5' ends aligned properly (in terms of sensitivity), so all the YASRA-templates comprising heavy gap penalties perform fairly poor as soon as there's a gap nearby the 5' end.

The idea behind having such severe gap penalties is that 454 often incorrectly calls the length of homopolymer runs, introducing what will look like short gaps. As used within yasra (an assembler from the Miller Lab, not in galaxy) these settings are probably appropriate. But this is not an ideal general solution because it can keep us from discovering true gaps. A better solution would probably be to have less-severe gap penalties, with an additional context- related gap penalty (or reward) for gaps at homopolymer runs. However, it would be costly to add this to the alignment core inside lastz. The problem with gaps or mismatches close to the end of a read is discussed in the lastz readme file, in the section "Y-drop Mismatch Shadow". The situation can can be improved by using the --noytrim option. This option was added to lastz after the wrapper was written, and so is not currently available from galaxy. --noytrim tells lastz to accept a lower-than-maximal-scoring alignment if it can reach the end of the read. I intend to add that into the yasra settings, but changing those raises an issue of backward compatibility that I need to resolve. I hope that helps. Please post a reply if I've left something unanswered or if you have other thoughts on this. Bob H On Jun 6, 2011, at 6:47 AM, Appelt, Uwe wrote:

Hi @All,

short version: Is it possible to specify more arguments in "Full parameter list"- mode, particularly those that're implicitely described in YASRA-mode (match/mismatch rewards and step-size (Z/step))?

long version: I'm dealing with 454 reads and it's crucial to the scenario to have the 5' ends aligned properly (in terms of sensitivity), so all the YASRA-templates comprising heavy gap penalties perform fairly poor as soon as there's a gap nearby the 5' end. However, heading to "Full parameter list"-mode leads to excessive CPU-use, because (presumably) the step-size (default=1?) is left unset. Also, it'd be great to be able to alter not only gap penalties, but match/mismatch rewards as well. (Obviously a mismatch would cause the same problem).

Examples: AAAAAAAAAA (target) AAAAATAAAA (query)

=> I need the alignment boundary to be found at position 1, rather than behind the mismatched T and this cleary doesn't work as long as the mismatch penalty is too large (same applies for gap-open/extend penalties).

Thanks in advance and Cheers, Uwe ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Hi Matloob, Others should contribute their experiences as well but for the Galaxy VM and cloud, we use Ubuntu 10.04. Also, to automate the machine setup, we have a scripts that perform all of the required setup steps; the scripts are usable by anyone for a range of machines and are available here: https://bitbucket.org/afgane/mi-deployment/ Good luck, Enis On Tue, Jun 7, 2011 at 8:00 AM, Matloob Khushi <matloob.khushi@sydney.edu.au

wrote:

Hello Galaxy Users

We are anticipating setting up a local instance of Galaxy and wondering what is the most popular (or best) flavour of Linux people out there using.

I wonder which OS on UseGalaxy.org has been used. Thanks for your help.

Regards Matloob PhD Candidate

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Matloob Khushi wrote:

Hello Galaxy Users

We are anticipating setting up a local instance of Galaxy and wondering what is the most popular (or best) flavour of Linux people out there using.

I wonder which OS on UseGalaxy.org has been used. Thanks for your help.

Hi Matloob, The public Galaxy server runs Solaris 10. The tools run on two clusters, one running Debian Squeeze and the other running RHEL 5.6, both amd64. You might find that a specialized distribution like BioLinux or Scientific Linux may pre-package many of the tools you're interested in, which would make setup a bit easier. --nate

Regards Matloob PhD Candidate

___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:

http://lists.bx.psu.edu/listinfo/galaxy-dev

To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/