Pipeline in WGS mode appears to require target_bed

[lfearnley]

Description of the bug

When I run the pipeline in WGS mode target_bed must be supplied, or it feeds a null value to TABIX_PBT, causing the pipeline to crash.

The documentation suggests that target_bed is optional.

Command used and terminal output

No response

Relevant files

No response

System information

nf-core/raredisease 1.0 (current git master)

[ramprasadn]

Hi @lfearnley! Could you share your nextflow.log from a failed run?

[lfearnley]

Hi @ramprasadn - will do once it's available; I've had another run failure on a different issue.

Speaking of which - I'm running raredisease on GRCh38 WGS using the install instructions and encountering a reasonably large number of issues; how did you want me to handle these? Github issues with 1 per problem/query, or email?

[ramprasadn]

Sounds good!

That's concerning..
I think it'd be better if you open a Github issue for each problem/query, as it will allow other users and devs to pitch in with their experiences. 😄

[lfearnley]

Sure thing! Not too concerning - I think most of what I'm hitting is related to documentation/defaults that aren't getting set for some reason. I'll start with two I can think of off the top of my head.

On this issue though, a related question - running the pipeline in WGS mode seems to still result in PICARD_COLLECTHSMETRICS running. I'm not sure that makes sense?

[fa2k]

I also had this issue with intervals file and ended up adding a bed file for the whole genome. I agree that the best would be to disable CollectHSMetrics when using WGS, as it's not applicable. @lfearnley I have many of the same issues and you can see some notes (quite terse, sorry) in my repo README https://github.com/fa2k/raredisease-configs/tree/main , a bit down under Reference Data. I've also had great benefit from Clinical Genomics's repo https://github.com/Clinical-Genomics/reference-files/ and the test datasets. I think it's great that you're making issues in github instead of just working around it like I did, though.

[lfearnley]

@fa2k Thanks so much for that!

The only thing I'd check/flag in your notes (which are immensely helpful - there's one or two steps I've yet to debug that they clear up for me) is that the gnomAD SV 2.1 listed is possibly aligned against hg19 and the other files are aligned against GRCh38. I've been using the gnomAD 2.1.1 GRCh38 liftover from dbVar which is linked at gnomAD's download page if that helps for an update.

[fa2k]

Thanks @lfearnley for the correction on gnomAD SV, this will save me a lot of headaches:) (I'll also try to adapt to the new changes in the dev branch, there are some new arguments.)

[ramprasadn]

Fixed in #395