I have the

VCF_PHASE_SHAPEIT5

. It takes as input: • ch_vcf (meta[id, optional(chr)], vcf, index): mandatory target variants to be phased (can be multi/single sample, multi/single chr) • ch_chunks (meta[panel_id, chr], regionout): optional list of successive regions in a chr to perform the phasing on (multiple / chr), obtained from chunking the panel so linked to panel_id • ch_ref (meta[panel_id, chr], vcf, index): optional chromosome level VCF of a reference population haplotypes (one / chr) • ch_scaffold (meta[panel_id, chr], vcf, index): optional chromosome level VCF of some haplotypes that overlap ch_vcf position and samples (one / chr) • ch_scaffold (meta[chr], region, map): optional region and geneticmap to perform chunking and phasing (one / chr) Here are the use case: • work with only input vcfs (multi-sample, multi/single chr), + optionally chunks (multi / chr) and map (one / chr) • work with input vcf (multi/single sample + multi/single chr) + panel/scaffold (one / chr) + optionally chunks (multi / chr) and map (one / chr) I need to properly combine the different channel based on the data provided. Currently the sbwf do a join on all channel and let the user in charge of doing the whole meta modification before using it. This is no ideal and add a lot of meta map manipulation for the second use case. My idea was either to: • use a boolean to ask if ch_vcf needs to be joined or simply combined (this works for most cases but not if ch_vcf is split by chr) • use an array of common meta to perform the join on (should work but need a way when ch_vcf is not split by chr)

I don’t fully follow the the issue I think, but can you not just do the join/combine on the subset of meta that is relevant? i.e.

[id, chr]

Even if that means injecting a dummy

chr

for samples where the vcf is not split? i.e.

chr: 'all'

This is indeed what I would like to test now

I’ll look at the code now it’s linked

Yeah, that was the first implementation but this was not a good idea 😅

I would strongly recommend creating a single clear join/combine strategy, documenting what is being joined on, and leave it to users to prepare their input channel

meta

maps with the correct information

> I would strongly recommend creating a single clear join/combine strategy, documenting what is being joined on, and leave it to users to prepare their input channel

meta

maps with the correct information I think joining on an array of common meta might be the way to go, but then it's the GLIMPSE_CHUNK that doesn't work anymore when giving ch_vcf without chr and ch_map with chr. github.com/nf-core/modules/pull/13050 (I need to try a variation). > In fact, the internal tools `glimpse`/`shapeit5` seem to take most of these values as a single input channel, so why not just make the user provide a single input channel with the correct cross-joining already done? This could be a way

I don’t really understand though why you can’t have them provide ‘chunks’ as part of the single input channel still I guess? There seems to be a desire to to a lot of complex joining here, but I feel the subworkflow would be maximally flexible if the user essentially chooses that by providing an already joined input channel. And you don’t need the

chunk

boolean afaict, you could simply filter the input channel on the presence of a value in

ch_chunks

(or the chunk field of a single large input channel)

The idea is that you can have multiple chunks for a given chr so SHAPEIT5_PHASE_COMMON run for N_vcf_id x N_panel_id x N_chunks. The simpler would be to have a single input with [[id, panelid, scaffoldid, chr], vcf, pedigree, ref, scaffold, chunk, gmap] directly and avoid the glimpse2 chunk preprocess. > And you don’t need the

chunk

boolean afaict, you could simply filter the input channel on the presence of a value in

ch_chunks

(or the chunk field of a single large input channel) True