Looking at your proposal, I think the keywords would be: • Model Fitting • Evolutionary models • Hypothesis testing • Multi sequencing alignment • Evolutionary rates • Evolutionary models So I think 'evolutionary' is the most important bit here. 'evomodeller'? 'evomodeltester'?

<!subteam^S016E36N7TQ> any further suggestions?

Hi! As I mentioned on the pipeline proposal issue, I'm specifically working to develop a pipeline (genephylo) to produce the input files for this type of analyses! The goal was to first publish genephylo then propose a new pipeline to add downstream analyses, but you guys beat me to it (for which I am immensely grateful actually)

we're working on genephylo during the hackathon in my local hub, hopefully we can progress toward a first version (probably not by the end of the hackathon though) after genephylo v1 is out I'd be happy to help with integrating more methods in this pipeline!

Hi! That would be amazing! I'd be happy to work on integrating the outputs of genephylo as inputs into this pipeline once it's published

I saw that there is another pipeline called multiplesequencealign and was curious if genephylo does something similar?

The goal is to use part of the multiplesequencealign pipeline as a subworkflow in genephylo

but multiplesequencealign is not adapted to produce the right files for a pipeline like yours (no phylogenies produced, and none of the alignments produced are codon-aware)

also, in genephylo I'll automate the retrieval of sequences through blast and do curation steps to ensure we produce the msa and tree for our gene of interest (so no contamination from paralogs etc, hopefully)

that way the user can just provide the fasta of their gene of interest (either nt or aa) and they end up with a codon-aware msa and the corresponding tree that they'll just be able to plug into your pipeline afterwards if they wish to

very hands off, much practical (hopefully) 👍

Oh that's perfect! I was originally considering adding the alignment and tree construction steps into my pipeline but eventually decided against it. So it's good to hear that others are working on it

@Lea Picard (leapfroggie_) any good ideas for a better name for this pipeline? (i kind of like the phylo prefix, because it binds nicely with genephylo as an upstream pipeline)

More name ideas: • phylomodeler • phylotester • phyloselection • phyloseqanalysis

I commented above that maybe we could also use the gene prefix to make it obvious that these analyses apply to coding genes? (vs some positive selection analyses that can be done on non-coding regions)

geneevotester genephylotester genephylomodeltester for example? otherwise phylomodeler, phylotester or phylomodeltester feel nice and descriptive to me

I think genephylomodeler could be a good name as a downstream pipeline to genephylo

has renamed the channel from ‘phyloanalysis’ to ‘genephylomodeler’

Test data branch: https://github.com/nf-core/test-datasets/tree/genephylomodeler

Ah wait you already had one

OK merged the old

phyloanalysis

branch into

genephylomodeler

Note: don't forget to document where the test-data is from/generated on the main README!

The name has been updated to

genephylomodeler

!

Hi. So I'm now in pond lab at temple, where hyphy is developed. This is very cool. We've a nf workflow ourselves that while built on nf-core framework we didn't propose to submit here. It's meant for exploring across viral genomes rather than specific genes, starts w unaligned fasta. Well possibly make others, also w specific purposes. Might be nice to share notes though, pull from a consistent pool of shared modules and subworkflows etc. there is a tool called drhip we have for ex produces nice tabular summaries for a bolus of hyphy Json might be helpful to you here.

Hi! I was wondering if it would be useful to code all the nf-core modules (for hyphy at least) that are included in the pipeline? I have started with (only) BUSTED for now, but I think it would be nice so that they can be integrated in the pipeline directly, which reduces the amount of work for review at release time, as well as versions updates and the like. Once the first module is done it should be fairly quick to do the others as the test files and large parts of the modules would be exactly the same. I mention this notably because I recently tried to run the pipeline for some GARD analyses, and it failed because the GARD local module is implemented with "process_single", which limits it to 1 CPU and 4h of runtime. Most analyses (at least for the 15 I tried to run) far exceed that. I know it's possible to update this via config, but I think it would be easier to just have a process label that is appropriate for most use cases. On another note, I'm waiting for a review for a conda package so I can then implement a module for Biopp, a library that allows for running selection models like the ones in codeml (except faster and with easier access to parametrization), as I would like to also add it to the pipeline.

Well I've ended up making the modules for 7 out of 10 of the methods implemented in the pipeline (ABSREL BGM BUSTED FEL FUBAR MEME and SLAC), as they basically all follow the same input schema. I'm working on GARD at the moment but I have a problem with my test dataset

Error:
Internal error 
Internal error in ComputeBranchCache (branch gard.tree.part_1.Node2, eval #348133 ) reversible model cached likelihood =  -7298.887093143881, directly computed likelihood =  -7298.899177285343. This is most likely because a non-reversible model was incorrectly auto-detected (or specified by the model file in environment variables; for smaller errors, this could be due to numerical instability of calculations for larger alignments). To treat numerical errors as warnings, please specify "ENV=TOLERATE_NUMERICAL_ERRORS=1;" as the command line argument. This often resolves the issue, which is indicative of numerical instability.

The test pass if I add "ENV=TOLERATE_NUMERICAL_ERRORS=1;" to the command line in the module. However, I wonder if it should be included in the module itself, as that might prevent this error from showing up in regular analyses? I'm not sure how often it actually occurs. If it's better not to do it, I can just use another test dataset pilfered from Datamonkey (the small one probably). If anyone has any input? @Nina Xiong @Danielle (sorry to bother you but since you're from Pond lab I thought I would use the opportunity 😅)

oh very cool, nice progress 🎉 id put this in user control. id not make it the default and certainly not have it always on, but there is real reason an informed user might choose to ignore it

I asked about MPI processes in #C043FMKUNLB, and it does seem that using HYPHYMPI processes might make the modules (and consequently the pipeline) have some portability issues

Ok I'm done with 9 out of the 10 modules included in GPM, just missing RELAX as I've never used it so I'm not sure how to format the foreground vs reference tags (so I can build a test for the module) Also idk if other modules should be made (PRIME etc)? I guess one for DRHIP would be good at least?

since it seems relevant to this group, thought id share a preprint introducing the foundation model that were effectively treating as the successor to hyphy biorxiv.org/content/10.64898/…