Hey everybody, coming back to the discussion that ...
# microscopy
f
Hey everybody, coming back to the discussion that @Konrad Rokicki and I had recently, I have a question for the channel, since the people that would most likely deal with this data would be in here. As mentioned, I am finishing a pipeline to process Molecular Cartography data from Resolve Biosciences. Currently, my pipeline is not on the nf-core template, but I would like to port to it, to get more standardized code and unit testing etc. If I port it, that means it could very easily be made into an actual nf-core pipeline (which I would call something like nf-core/molcart, for molecular cartography). This would be similar to (https://nf-co.re/spatialtranscriptomics), which is a pipeline specifically for VISIUM data. Now the question is, whether we want to make multiple pipelines for different FISH based assays, such as Molecular Cartography, Vizgen etc, or do we want to build one massive FISH analysis pipeline, that can have different workflows to process different data types? With modules I think we could create separate pipelines (and subworkflows) for major technologies, making it easier to configure each pipeline and not cram every possible scenario into one giant mega pipeline. I think the different technologies often have vastly different start points and data types to warrant separate pipelines. The two possibilities I see are: 1. Make a separate pipeline for each major technology (nf-core/molcart, nf-core/vizgen, nf-core/xenium) 2. Make 1 in-situ hybridization based pipeline that has different workflows for different technologies (i.e. nf-core/FISHfactory or something with workflows Vizgen, Molcart, … ) What do you think, I would love to hear your input!
1️⃣ 3
p
Guidelines / general nf-core way of doing things has been (1). One pipeline per data / assay type. There are some exceptions and the lines are often blurry when defining what exactly that means, but I'm wary of mega-pipelines. #CJRH30T6V and #C03D38JNFNJ should hopefully reduce duplication of work.
👍 1
f
Awesome, I think that speaks very much toward the one pipeline per technology argument. 1. Proposing the pipeline in #CE6SDEDAA via the Pipeline proposal workflow💍 2. Already port my pipeline to the nf-core template (this will be helpful even if not an nf-core pipeline in the end, as it will add consistency to the modules etc. Currently im already using nf-core modules we wrote during the hackathon, but also use a lot of manual processes I haven’t modularized yet. Long-term they should all become modules). nf core 3. Question: I can write the code in the master branch or dev while developing? I am asking since I added some code to master of my fork already and don’t wanna start from scratch 😱. Pipeline tutorial says either or… 🙏 4. Work on finalzing the pipeline. I am using the results generated by this pipeline of this for an upcoming analysis of a paper, so I could cite the non-released pipeline version and then work towards a release IF accepted as a future nf-core pipeline, otherwise finalize outside of nf-core, right? cattyping 5. Hopefully be included into nf-core and making a first release in the future mergecon Does that all make sense or am I missing something?
Also, related to this question, please see my question regarding #C01BB6T15NF for imaging data @Phil Ewels gratitude thank you
p
Dev/master doesn't matter so much before first release. My preference would be to delete dev, then rename master to dev. Then when you're doing the first release you can just branch dev to a new master again and reset the default to that.
👍 1
But that's maybe a little convoluted for not much gain
f
Thanks also for your input @Konrad Rokicki and @Tong LI! I will move forward with making the Molecular Cartography pipeline using the nf-core template then and we will see if it will become an nf-core pipeline in the future 🙂 !
👍 2
One thing that I already noticed when trying to setup my pipeline, is that the default pipeline template currently includes a lot of checks and validations for genomic references and paramters that will not exist for #C051C6071S4 but also for other areas unrelated to genomics. As nf-core grows and different fields and areas join, is there any plan to include a barebone template without any of the genomic checks and validations? This could be helpful, so that not everyone who builds a new pipeline for #C051C6071S4 or other fields has to manually delete all those validations each time!
➕ 1
p
There's already a template flag when creating a pipeline to not include reference genomes I think, right?
Or do you mean more than this?
I'm happy to remove, but I think that having examples is generally better than relying on people reading the docs.. So don't want to remove that value. Would need some thought.
f
Ahh I wasn’t aware there was already settings in the pipeline creation step to get around reference genomes, thanks @Phil Ewels! I will check when creating a new pipeline and make a list of things that wouldn’t apply to imaging and that people would have to manually remove and let you know here!
• `igenomes`: removes pipeline options related to iGenomes. Including the
conf/igenomes.config
file and all references to it.
So there's probably more that could be removed. Feel free to start noting this stuff down in an issue (or better still, a PR 😉 )
k
Along these lines, I just added a PR to make multiqc optional, so that we can send emails from pipelines that don’t support multiqc (yet?) https://github.com/nf-core/tools/pull/2273/ @Phil Ewels what are your thoughts about how MultiQC applies to non-genomics pipelines? Should we be looking into supporting MultiQC reports in our tools? A couple caveats: 1. I’m often working with tools I didn’t write and can’t modify. Do you know of examples where MultiQC support is added on in a separate module, or as a script that augments the original tool without changing its codebase? 2. One characteristic of large microscopy image pipelines is that they often process one “sample” at a time, since these are massive amounts of data and you need to often work with each sample for a while before you get a good result. Not sure if there’s as much of a reason for MultiQC in that case, unless maybe to have a consistent report GUI?