just want to get this all resolved by the end of the week so that it can got into next weekend's .eu update
“BTW, it doesn’t bother me, but I think there is a problem with the column names in the NextClade tables: https://galaxy.hpc.ut.ee/datasets/8fb1cd32e9c26adb/display/?preview=True. There is a mismatch between column name and content from some point (and in total one less column name than there are columns), I think the column name “insertionsmissing” should actually be two column names “insertions” and “missing”"
Thanks!
and they got the error exactly... there was a typo
btw bioconda/bioconda-recipes#28845 - might as well do the version update and this bugfix at the same time
pvanheusden: just catching up with everything that has happened over my holidays.
In the latest version of the Pangolin tool, what exactly is the consequence of choosing to use the UShER model?
Does that imply that the pangoLEARN source will be ignored no matter what you choose there, or are these different things?
In the latest version of the Pangolin tool, what exactly is the consequence of choosing to use the UShER model?
Does that imply that the pangoLEARN source will be ignored no matter what you choose there, or are these different things?
no, the pangoLEARN DB contains the data used in the UShER model.
Let me see if they have release notes on this - there is a bunch of new stuff I don't quite understand - Scorpio being the other part
ok so
scorpio seems to specifically related to identifying VOCs based on constellations of mutations.
Seems so, yes. I have yet to understand what exactly this adds to the existing pangolin functionality.
yep. it would be good to have a better description & a changelog
Definitely, though it's always easy to complain about other projects' documentation ;)
Ok, so it seems that if you run pangolin in
--usher mode, it will use lineageTree.pb from the paangoLEARN data as the model (tree) - https://github.com/cov-lineages/pangolin/blob/4a4f5ec390efba89524ac6f4365981199607c1cb/pangolin/command.py#L295
Makes sense, but the command line help is really confusing.
wm75 (Wolfgang Maier): I checked with the
ivar_variants_to_vcf.py authors and there was no compelling reason to format things the way they did it, so I implemented a change to move the info to the INFO block. So I think galaxyproject/tools-iuc#3716 is now done
I'm busy with two talks this morning but will review and merge early in the afternoon
From a quick first look: Can you eliminate the genotype and FORMAT column altogether then?
GT is not worth keeping it seems to me.
Another improvement could be to rename
ALT_FREQ to the much more common AF to enhance interoperability with other tools.
yeah I can remove GT and FORMAT... since its not really being used.
so, it's been a while, but constaxonomy is 3-column, name, taxonomy and number of OTUs, see here. And the reference taxonomy is just the names and the taxonomy (without the counts). You could probably get exaples for both from the GTN tutorial, a ref taxonomy files is used as reference, and a cons.taxonomy is generated for our samples along the way.
(but not 100% sure here)
they don't seem to distinguish between the filetypes on their wiki: https://mothur.org/wiki/tags/#file_types
3 replies
I'm working on different approaches to plotting amplicon depth... a report that's quite useful from a SARS-CoV-2 analysis point of view. I've got 2 different tools that do similar but not the same thing - i.e. they present slightly different information... not sure how to deal with this from an IUC point of view: I know there has been some reluctance in the past to have too many similar tools?
I guess that question is difficult to answer. I personally prefer separate tools over many options within a tool, but if you're in control of both scripts a single tool might make sense ?
2 tools within a repo might be fine too ?
Got a fun one here for workflow version pinning breaking because the version of Python was not specified: peterjc/pico_galaxy#37
What I think is happening is my old workflow (on the Tool Shed) is pointing at an old Python-2-only version of my RXLR tool, which breaks under a modern Python-3 based Galaxy. The RXLR tool itself was updated for Python 3, but the workflow was not updated to point at this.
Another question, do people still share workflows on the Tool Shed? There isn't a category for them, and the newest search result for "workflow" is from 2020, second and third newest from 2019.
WorkflowHub it's myExperiment 2.0, it's from the same people.