galaxy-user February 2011

galaxy-user@lists.galaxyproject.org

70 participants
85 discussions

Text Manipulation
by Felix Hammer 22 Feb '11

22 Feb '11

Hi, is there a way to manipulate the different values in the column of a tab sepparated file (i.e. change all chr1@sdfasdfasdfasdf to chr1 using regexp). thx, Felix

3 3

Re: [galaxy-user] Installing Galaxy locally
by Jordi Rambla de Argila 22 Feb '11

22 Feb '11

Hi David, I'm a biologist working as a computer consultant for 20 years. Although Galaxy is quite easy to install, as Kanwei said, you should consider that installing a local Galaxy for "personal" use is qualitatively different than asking to install Galaxy for general use. In the later, the computer team must plan for several aspects as: user authorisation, data file organization and life cycle, backups, required tool maintenance, reference genomes maintenance... Depending on the complexity this is a significant amount of work, not just a couple of man-days job. Hope this helps Jordi Rambla MsC Genetics & Bioinformatics Barcelona Enviado desde mi BlackBerry® de Vodafone -----Original Message----- From: Kanwei Li <kanwei(a)gmail.com> Date: Mon, 21 Feb 2011 23:28:27 To: <D.A.Matthews(a)bristol.ac.uk> Cc: <galaxy-user(a)bx.psu.edu> Subject: Re: [galaxy-user] Installing Galaxy locally Hi David, Yes, it is free and easy to set up, and we have instructions here: https://bitbucket.org/galaxy/galaxy-central/wiki/GetGalaxy Thanks! Kanwei On Mon, Feb 21, 2011 at 5:42 PM, David Matthews <D.A.Matthews(a)bristol.ac.uk <mailto:D.A.Matthews@bristol.ac.uk> > wrote: Hi, I am not a computer person and very much like using Galaxy because its nice and easy for non-bioinformaticians. Tomorrow I am going to have a meeting with the computer science department here at Bristol and I am hoping to persuade them to install Galaxy within the High Performance Computing Centre for University of Bristol users. As I understand it this is relatively straight forward - that is to say the project was designed for them to install the whole thing locally and reproduce the set up here so I and others can use it here instead of clogging up your machines with our data and requests (!). Is this right? There are no fees or anything and this is something most computer centres should be able to do? I know this may seem a silly question but it seems prudent to ask! Cheers David _______________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org <http://usegalaxy.org> . 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/

1 0

galaxy fetch sequences question
by Valerie Reinke 22 Feb '11

22 Feb '11

Dear Galaxy expert: I have recently been using Galaxy and have been thrilled with its utility and ease. Thank you very much! I have one question - I am trying to fetch sequences (for C. elegans ce4 genome) for intervals in a tab delimited file that has been used successfully as an interval file for other types of Galaxy queries (attached). However, when I try to fish out the sequences associated with these intervals (for MEME analysis), I get empty returns, and the same warning (below). Where is it getting the 544 from? What do I need to do to make it read the file correctly? I tried file conversion, getting rid of the extra columns, and changing the chromosomes to I, II, III, etc (the canonical names in the worm field), and nothing seems to do the trick. Any suggestions would be helpful. Thanks! Valerie Warning message: empty format: fasta, database: ce4 Info: 2720 warnings, 1st is: Unable to fetch the sequence from '3525' to '544' for build 'ce4'. Skipped 2720 invalid lines, 1st is #1, "Chr1 3525 4069 281 21 3.25E-58" ------------------------------------------------ Valerie Reinke Associate Professor Dept Genetics Yale University School of Medicine 203-785-5228 valerie.reinke(a)yale.edu

2 1

Re: [galaxy-user] galaxy
by Kanwei Li 22 Feb '11

22 Feb '11

Hello Musa, I am forwarding this question to the mailing list so that someone better qualified can help you. -K On Mon, Feb 21, 2011 at 12:18 PM, Musa A. Hassan <mhassan(a)mit.edu> wrote: > I am trying to use galaxy for the first time and am running into some early > problems. While trying to upload my file which is basically a fq containing > illumina short reads, the file won't upload. When I try the fastq extension > of the same file, it does but then the file isn't recognized by the groomer > hence it's like I have no file uploaded. Do you know how I can circumvent > this problem. > > > Musa Hassan, PhD > Wellcome Trust-MIT Fellow > Massachusetts Institute of Technology > Department of Biology, 68 > 77 Massachusetts Avenue, > Cambridge, MA 02139 > USA

2 1

look for wig file
by Ying Zhang 21 Feb '11

21 Feb '11

Hi: everybody I am using tophat in galaxy to analyze my paired-end RNA-seq data and find out that after the tophat analysis, we can not get the wig file from it anymore which is used to be able to. Do you have any idea of how to still be able to get the wig file after tophat analysis? Thanks a lot! Best Ying Zhang, M.D., Ph.D. Postdoctoral Associate Department of Genetics, Yale University School of Medicine 300 Cedar Street,S320 New Haven, CT 06519 Tel: (203)737-2616 Fax: (203)737-2286

1 0

February 18, 2011 Galaxy Development News Brief
by Jennifer Jackson 19 Feb '11

19 Feb '11

February 18, 2011 Galaxy Development News Brief http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2011_… ---- Get Galaxy! http://bitbucket.org/galaxy/galaxy-central/wiki/GetGalaxy new: % hg clone http://www.bx.psu.edu/hg/galaxy galaxy-dist upgrade: % hg pull -u -r ca0c4ad2bb39 ---- What's New = galaxyproject at Twitter = Join us at Twitter for the latest updates on development projects, conferences and training, and all things Galaxy! #usegalaxy http://twitter.com/#!/search/galaxyproject = New Ways to Search Data Libraries = In addition to searching on data library names and descriptions, we have introduced the ability to search on attributes of library datasets. Two different approaches to searching library datasets are supported 1. Searching with whoosh https://bitbucket.org/mchaput/whoosh/wiki/Home 2. Searching with Apache's Lucene http://lucene.apache.org/java/docs/index.html (Contributed by Brad Chapman) The public Galaxy instances hosted at Penn State University use the whoosh implementation, while Brad Chapman's instance uses the Lucene implementation. Choose either of these implementations for your local Galaxy instances (but not both). There are two new config settings in the "Data Libraries" section of universe_wsgi.ini.sample for these implementations (again, uncomment only one of these if you choose to use this feature): # Search data libraries with whoosh #enable_whoosh_library_search = True # Whoosh indexes are stored in this directory. #whoosh_index_dir = database/whoosh_indexes # Search data libraries with lucene #enable_lucene_library_search = False # maxiumum file size to index for searching, in MB #fulltext_max_size = 500 #fulltext_noindex_filetypes=bam,sam,wig,bigwig,fasta,fastq,fastqsolexa,fastqillumina,fastqsanger # base URL of server providing search functionality using lucene #fulltext_url = http://localhost:8081 Details for searching with whoosh You will need to build indexes on a regular, timely basis for searching your library datasets. You can do this by running the following script included in the distribution: % <your galaxy install dir>/scripts/data_libraries/build_whoosh_index.sh Running this script will build whoosh indexes in the directory named by the config setting labeled whoosh_index_dir shown above. We recommend adding something like the following setting to your Galaxy server's cron settings to keep the indexes current: 0,30 * * * * cd /var/opt/galaxy/g2test/galaxy_test ; bash ./scripts/data_libraries/build_whoosh_index.sh The above setting rebuilds the indexes every 30 minutes. You may want to build them more often because search results will include only those library datasets that were indexed the last time the script was executed. In other words, if a library dataset was uploaded after the whoosh indexes were created, it will not be returned in search results even if it meets the search criteria. Using whoosh, you can search on the "name", "info", "message" and "dbkey" attributes of library datasets using the following new search box displayed at the top of the "Data Libraries" page: http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2011_… Clicking the "Advanced search" link below the search box allows you to search data library names and descriptions as you did in the past: http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2011_… Details for searching with Lucene If you use the Lucene implementation instead of whoosh, there are a few differences. You'll need to build Lucene indexes using the following script: <your galaxy install dir>/scripts/data_libraries/build_lucene_index.sh In addition to the "name", "info", "message" and "dbkey" attributes, this implementation will also index the contents of your library datasets. You should decide on the optimal values for the following config settings for your Galaxy instance: # maxiumum file size to index for searching, in MB #fulltext_max_size = 500 #fulltext_noindex_filetypes=bam,sam,wig,bigwig,fasta,fastq,fastqsolexa,fastqillumina,fastqsanger You'll also need to decide on a value for the following config setting: # base URL of server providing search functionality using lucene #fulltext_url = http://localhost:8081 = Managing disk space with Data Libraries = Adjusted the cleanup_datasets.py script to more correctly handle the lifecycle of Library Datasets. Managing library datasets is a bit complex, so here is a scenario that hopefully provides clarification. The complexities of handling library datasets is mostly contained in the delete_datasets() method in the cleanup_datasets.py script. Example of usage: 1. Assume we have 1 library dataset with LibraryDatasetDatasetAssociation -> LibraryDataset and Dataset This dataset would have the following database column values: LibraryDatasetDatasetAssociation deleted: False LibraryDataset deleted: False, purged: False Dataset deleted: False purged: False Now a user deletes the associated dataset from a data library via a UI menu option. This action results in the following database column values: LibraryDatasetDatasetAssociation deleted: False LibraryDataset deleted: True*, purged: False Dataset deleted: False, purged: False 2. After the number of days configured for the delete_datasets() method (option -6 in the cleanup_datasets.py script) have passed, execution of the delete_datasets() method results in the following database column values: LibraryDatasetDatasetAssociation deleted: True LibraryDataset deleted: True, purged: True Dataset deleted: True*, purged: False 3. After the number of days configured for the purge_datasets() method (option -3 in the cleanup_datasets.py script) have passed, execution of the purge_datasets() method results in the following database column values: LibraryDatasetDatasetAssociation deleted: True LibraryDataset deleted: True, purged: True Dataset deleted: True, purged: True (dataset file removed from disk if -r flag is used) This scenario is about as simple as it gets. Keep in mind that a Dataset object can have many HistoryDatasetAssociations and many LibraryDatasetDatasetAssociations, and a LibraryDataset can have many LibraryDatasetDatasetAssociations. Another way of stating it is: LibraryDatasetDatasetAssociation objects map LibraryDataset objects to Dataset objects, and Dataset objects may be mapped to History objects via HistoryDatasetAssociation objects. ---- Updated & Improved = Current Tools = * Update FASTX tool wrappers to handle fastqsanger formats. * The BLAST+ tools are now uncommented in the sample tool configuration. * Fix an Rpy syntax problem in the Histogram tool that was causing the tool to fail in some local installations. * Enable Cuffcompare to take an arbitrary number of input GTF files. * Add GTF sniffer to datatypes config sample file. = New Tools = * Added a Line/Word/Character counter to Text Manipulation tool group. * Extended Extract Genomic DNA tool to support GFF/GTF features and custom genomes: ** This is especially useful for extracting genomic data that correspond to transcripts in GTF format, as is produced by Cufflinks. ** Tool also now accepts sequence data from a history item, enabling the extraction of data from custom genomes. = New Community Tools Added (Tool Shed) = * Velvet, ABySS, Minimus2, Phrap, and Newbler. http://community.g2.bx.psu.edu/ = Data Libraries = * Fix a bug that included the option for a regular (non-admin) user to upload a directory of files when the config setting existed, but the user's directory did not exist. Instead of throwing an exception, an attempt to create the directory will now be made. If the attempt fails, the option to "Upload a directory of files" will not be included in the select list on the upload form for that particular user. * When browsing a data library, only display the check boxes and the actions to perform on multiple selected datasets if library datasets are displayed. * Clean up the behavior when performing an action on multiple library datasets. Instead of throwing an error and not allowing the action on any of the datasets if the user is not authorized to perform the action on one of them, all "unauthorized" datasets are now left alone and the action is performed on all datasets for which the user is authorized to perform the action. Appropriate messages detail what occurred. * Allow regular users to delete multiple datasets returned from library dataset searches based on the behavior described above. * Do not include the "Select datasets for import into selected histories" option in the actions popup menu at the data library level if the library's root folder doesn't contain any accessible datasets. Make behavior the same for folder popup menus. * Fix a bug where a regular user could never see deleted library items when toggling show / hide deleted items in a data library. * Add a purged column to the LibraryDataset table. A LibraryDataset is marked "purged" when all associated LibraryDatasetDatasetAssociations are marked "deleted". = Workflows = * Workflow steps on the "Run workflow" page are now collapsible to just the title bar with the tool name and annotation. Steps without any inputs to be set will be collapsed by default. * When running a workflow, possible values for Input Dataset steps are filtered to datatypes that are valid for immediately subsequent steps, instead of just using 'data'. * Jquery1.5 workflow fixes with quotations and flagging of outputs. Workflows containing tools that are not loaded will now open in the editor instead of failing on the dictionary lookup. The offending nodes are marked as having an error state, and the workflow cannot be saved. This will enable users to at least look at and try to recover a workflow by removing (and potentially replacing) the offending steps, as well as providing a better view of what's actually wrong with the workflow. * Workflows will no longer try to run when required tools are not found. An error message is displayed with a link to the editor view (to fix the workflow). * Interval datatype now uses line estimates for large files. This fixes potential "'?' lines" seen by some users. * Removed "Annotation:" labels for a cleaner look on the run workflow page. * New History functionality now shows only the checkbox by default, displaying the input for a history name only when checked. * Tool text has been standardized to refer to datasets as such, instead of the older descriptor 'query'. * We now use the inflector utility to pluralize groupings. Fixes "Querys", etc. = Trackster = * Enhancements: ** Support large (10,000+) sets of chromosomes/contigs, as is often the case for low/non-model coverage genomes. ** Improve speed by streamlining data fetching and caching in Trackster. ** Add support for child tracks. ** UI hints for zooming out/in. ** Extend CIGAR string parsing to handle all operations (however, insertions still not fully supported). ** History dataset selection: show history name, show and order by hid in display. ** Modified interval index squish mode to display blocks and treat intervals as half-open. * Bug fixes: ** Fix CIGAR string parsing bug that prevented sequence data from being displayed correctly. ** BED files without score column or with scores that are floats can now be displayed. ** Better handling of error messages so that messages and data do not overlap. = User Interface (UI) = * Search improvements: ** Size of search box increases to show help text (column label). ** Help text is highlighted rather than hidden when user clicks on search box. ** Standard and advanced search divs are toggled correctly when moving between searches. = Galaxy Reports = * Clarify in the reports config that Galaxy reports do not support SQLite. * Add 2 new sample tracking reports and 2 new workflow reports, each of which provides the total number of items per month and the total number of items per user (per month). = Source = * Better egg version conflict resolution. Our eggs should always override dependencies installed elsewhere on sys.path. * Job runners are now loaded dynamically; changes to the source are no longer required. Existing 3rd-party runners will need to add a class to instantiate to the runner-global '__all__' list. See the provided runners for examples. * The Galaxy-side code for the LWR job runner by John Chilton is now included. Documentation in the wiki is forthcoming, to learn more see John's documentation at: http://bitbucket.org/jmchilton/lwr/ "LWR allows you to create a "cluster" out of any systems without installing specialized tightly integrated DRM software like PBS/SGE." = Bug Fixes = * Gracefully fall back to English if a client requests a locale not installed on the server. * Don't attempt to check for the python-daemon egg on Python 2.4 (it's used by an optional experimental component and is not compatible with Python 2.4). * The drmaa job runner would not always detect job completion on some systems. This change could also cause job failures to be considered successful job completions, but we have no way to test for these conditions. Please report if you discover this to be the case. * Migrating to database version 62 no longer fails for MySQL. Thanks Leandro Hermida. * Downloading eggs for offline systems works again. ---- = About Galaxy = Galaxy is supported in part by the following: NSF http://www.nsf.gov NHGRI http://www.genome.gov Huck Institutes of the Life Sciences http://www.huck.psu.edu The Institute for CyberScience at Penn State http://www.ics.psu.edu Core Team http://bitbucket.org/galaxy/galaxy-central/wiki/GalaxyTeam Use Galaxy Now! http://usegalaxy.org|Use Galaxy! Galaxy Project http://galaxyproject.org Galaxy Development Home http://bitbucket.org/galaxy/galaxy-central Follow Galaxy @ Twitter #usegalaxy http://twitter.com/#!/search/galaxyproject ---- Galaxy Project Team February 18, 2011

1 0

Re: [galaxy-user] SAM to GFF ?
by Peter 18 Feb '11

18 Feb '11

On Fri, Feb 18, 2011 at 12:35 PM, Felix Hammer <hammerf(a)cip.ifi.lmu.de> wrote: > > Hi Peter, > thx for the reply. > You're right I want to display mapped RNA seq data in gBrowse. > Currently I have the data in SAM format. > Maybe I can figure out a trick using the text manipulation tools. > thx, > Felix You forgot to CC the mailing list. If you want to use the data in GBrowse then why not use SAM/BAM directly? I've not tried it yet but I understand GBrowse can display BAM files... best asking on their mailing list if you need more details. This doesn't involve Galaxy directly though... Peter

2 1

SAM to GFF ?
by Felix Hammer 18 Feb '11

18 Feb '11

Hi, is there an easy way to use Galaxy to convert SAM to GFF? thx, Felix

3 2

Re: [galaxy-user] [galaxy-bugs] Galaxy tool error report from taka.nakada@nifty.com
by Ross Lazarus 17 Feb '11

17 Feb '11

Hi, Taka, I noticed that the full manhattan plot looks odd in the history I have shared with you, and I think it's because the offsets for some of your snp are wrong. For example, the very last marker in chr1 in your data is rs11488669. In your data, the offset is 2147483647 which is way beyond the end of chr1 - the genome is only 3B base pairs - so the manhatten plot looks clumpy instead of uniform. According to genome.ucsc.edu it is at chr1:153517269-153517769 I'm going to guess that your data (eg the map file) has at some stage been changed using spreadsheet software such as excel which can easily do strange things to numeric columns. If all your processing is inside Galaxy, these kinds of errors can be prevented. I can see you have tried unsuccessfully to upload some plink lped files in the history you shared - here's some information that might help you from a previous enquiry on galaxy-user a few weeks ago: ============================================== Hi, Sylvian, The plink/rgenetics lped and pbed (compressed) formats are special 'composite' Galaxy datatypes because the map and pedigree/genotype files need to be kept together correctly inside Galaxy. As a result, the upload tool requires that the file type be specified so all of the components can be properly uploaded and stored together. For example, to upload pbed data from your local desktop, choose 'Upload file' from the Get Data tools. When the upload form appears, the trick is that you *must* change the default 'Autodetect' in the first (filetype) select box to the specific rgenetics datatype - either 'pbed' as the format for compressed plink data (or 'lped' for uncompressed plink genotype data) as the very first step. Type the first few letters into the first box, and select the right one from the list that appears. Once this is done, you will see that the upload tool form will change to show three separate file upload inputs - one each for the plink xxx.bim xxx.bed and xxx.fam where xxx is the name you set when you ran plink to create the files, or for uncompressed linkage format two separate file upload inputs - the plink .ped and .map files. Now you can browse for the corresponding file for each input box from your local machine - be careful not to mix them up as the upload tool is unable to tell unfortunately. At the bottom of the form, I suggest you then change the genome build to the appropriate one (eg hg18 or hg19). Finally, I'd recommend that you change the 'metadata value for basename' (which will be the new dataset name) to something that will remind you what the data are - something more meaningful than the default 'rgenetics'. Click 'execute' to upload the data and create the new dataset in your history. Compressed (pbed) format is preferred so the upload is quicker. Note that some tools will autoconvert between lped and pbed so there is a delay the first time some tools are run on a new dataset. There are built in converters (use the pencil icon) also if you need them. I hope this helps - thanks for using Galaxy and Rgenetics - please let us know how you go and feel free to contact me if you have other questions. On Fri, Feb 18, 2011 at 9:26 AM, Ross Lazarus <ross.lazarus(a)channing.harvard.edu> wrote: > Hi, Taka. > > Thanks for trying the tool. Sorry to hear you are having problems with > your data. > Unfortunately, the history associated with this error does not have > any datasets with data in the format required for the Manhatten/qq > plot tool. > > The file you were attempting to use was a bed file. In fact it is not > even a valid bed format file because it has spaces instead of tabs as > delimiters. The tool is unable to parse the header row correctly so > you have the error about an index out of range on the header row. > > As the tool form explains, the input required is: > "Tabular Data is a tab delimited header file with chromosome, offset > and p values to be plotted" > > I tried changing the datatype from bed to tabular but discovered that > you have spaces as delimiters! So, I downloaded and repaired your > dataset by converting the delimiters to tabs interactively in python > so it is now in the required format and uploaded the first few > thousand rows to the original history and plotted it to check that the > tool works as expected. I also ran the plots for the entire million > rows and the plot is in the history. > > I have shared the new history with you and attached is a low-res > version of the resulting output from the first few thousand p values. > You should be able to find the history by choosing 'options' from your > current history then 'histories shared with me'. > > If you can ensure that the data are in the correct format (only use > tabs as delimiters and have a header row) then the tool should be able > to perform correctly. > Data in any other format is likely to cause the tool to crash. > > Thanks for using Galaxy - I hope it is useful for your research. > > In case you need to fix any other defective files, here's what I did: > > rerla@rosst61:~/Downloads$ python > Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) > [GCC 4.4.5] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> f = 'nakada.tab' >>>> bad = open(f,'r').readlines() >>>> sbad = [x.split() for x in bad] >>>> good = ['\t'.join(x) for x in sbad] >>>> good[:3] > ['CHR\tSNP\tBP\tA1\tF_A\tF_U\tA2\tCHISQ\tP\tOR', > '1\trs28659788\t713170\tG\t0.04094\t0.03725\tC\t0.08434\t0.7715\t1.103', > '1\trs3094315\t742429\tG\t0.1754\t0.1533\tA\t0.835\t0.3608\t1.175'] >>>> o = open(f,'w') >>>> o.write('\n'.join(good)) >>>> o.close() > > > On Fri, Feb 18, 2011 at 8:32 AM, <galaxy-bugs(a)bx.psu.edu> wrote: >> >> GALAXY TOOL ERROR REPORT >> ------------------------ >> >> This error report was sent from the Galaxy instance hosted on the server >> "main.g2.bx.psu.edu" >> ----------------------------------------------------------------------------- >> This is in reference to dataset id 2071026 from history id 485682 >> ----------------------------------------------------------------------------- >> You should be able to view the history containing the related history item >> >> 12: Manhattan_and_QQ_plots.html >> >> by logging in as a Galaxy admin user to the Galaxy instance referenced above >> and pointing your browser to the following link. >> >> main.g2.bx.psu.edu/history/view?id=df22bcb1488553c7 >> ----------------------------------------------------------------------------- >> The user 'taka.nakada(a)nifty.com' provided the following information: >> >> Hi, >> >> I am trying to run Manhattan and QQ plots using PLINK file, but have this error. Would you please let me know how to solve it. >> >> Thanks >> Taka-aki Nakada >> ----------------------------------------------------------------------------- >> job id: 1813212 >> tool id: rgManQQ1 >> ----------------------------------------------------------------------------- >> job command line: >> python /galaxy/home/g2main/galaxy_main/tools/rgenetics/rgManQQ.py '/galaxy/main_database/files/002/070/dataset_2070806.dat' "Manhattan and QQ plots" '/galaxy/main_database/tmp/job_working_directory/1813212/galaxy_dataset_2071026.dat' '/galaxy/main_database/tmp/job_working_directory/1813212/dataset_2071026_files' '0' '2' '8' 'false' >> ----------------------------------------------------------------------------- >> job stderr: >> Traceback (most recent call last): >> File "/galaxy/home/g2main/galaxy_main/tools/rgenetics/rgManQQ.py", line 318, in <module> >> main() >> File "/galaxy/home/g2main/galaxy_main/tools/rgenetics/rgManQQ.py", line 287, in main >> rlog,flist = doManQQ(input_fname,chrom_col,offset_col,p,title,grey,ctitle,outdir) >> File "/galaxy/home/g2main/galaxy_main/tools/rgenetics/rgManQQ.py", line 219, in doManQQ >> newhead = [ohead[chrom_col],ohead[offset_col]] >> IndexError: list index out of range >> >> ----------------------------------------------------------------------------- >> job stdout: >> >> ----------------------------------------------------------------------------- >> job info: >> None >> ----------------------------------------------------------------------------- >> job traceback: >> None >> ----------------------------------------------------------------------------- >> (This is an automated message). >> _______________________________________________ >> galaxy-bugs mailing list >> galaxy-bugs(a)lists.bx.psu.edu >> http://lists.bx.psu.edu/listinfo/galaxy-bugs >> > > > > -- > Ross Lazarus MBBS MPH > Associate Professor, HMS; Director of Bioinformatics, Channing Laboratory; > 181 Longwood Ave., Boston MA 02115, USA. Tel: +1 617 505 4850; > Head, Medical Bioinformatics, BakerIDI; PO Box 6492, St Kilda Rd Central; > Melbourne, VIC 8008, Australia; Tel: +61 385321444 > -- Ross Lazarus MBBS MPH Associate Professor, HMS; Director of Bioinformatics, Channing Laboratory; 181 Longwood Ave., Boston MA 02115, USA. Tel: +1 617 505 4850; Head, Medical Bioinformatics, BakerIDI; PO Box 6492, St Kilda Rd Central; Melbourne, VIC 8008, Australia; Tel: +61 385321444

1 0

Re: [galaxy-user] FASTQ type change
by Jeremy Goecks 17 Feb '11

17 Feb '11

Steve, I'm sending this question along to the galaxy-user list because it's likely of interest to others as well as yourself. Dannon, our resident workflow expert, should be able to answer your question. Thanks, J. On Feb 9, 2011, at 10:28 AM, Stephen Taylor wrote: > Hi, > > I seem to remember sending a question about how to change the type of fastq in a workflow to the galaxy-dev list so it can run vs bowtie without going through fastqgroomer. I think you replied to me about a tool that would do this but I can't seem to find the answer on the list or in my inbox? Is there a way to to do this or did I dream the question/answer?!:-) > > Kind regards and thanks, > > Steve > > > > > > > > >

5 9

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

galaxy-user February 2011