Hi ! I would be interested in a scientific review ...
# request-review
l
Hi ! I would be interested in a scientific review more than a technical one for github.com/nf-core/modules/pull/12852 I've been facing some issues with genetic maps lately and most of them come from duplicated or null values. I wonder if removing these problematic values and then recomputing the recombination rate is the best approach.
n
Can you explain a bit more in detail what/ why you are doing and which parts you would like feedback on?
I do not really see an alternative to removing the problematic values if they cause problems downstream, but i guess it would be good to know what's causing them
l
I've wrote some details in the PR description, the main point is that the genetic map I find can't be directly used by imputation software as they contains duplicated genetic distance (cm) and/or 0 values in the recombination rate field. The tool then crash when encountering these values (but not always the case 🤔). My idea was therefore to remove the problematic values and then recompute the recombination rate if already provided. The issue might be for region with many successive duplicated values, like 64.324596 cM is used from chr9 38743730 to 63571396 (centromere region). If we remove the duplicate, the imputation software will interpolate linearly the genetic distance accross the empty regions. But as the next values is quite close chr9:63574687 is 64.324981cM the rate will be close to 0. So I guess it would be fine.
n
Presumably it is not possible to call centromeric recommendation in the data you have, so it makes sense that the whole region gets a single value? My guess why it crashes is some issue with type guessing during import (if it is R).
l
The crashes comes in the downstream tools like
GLIMPSE_PHASE
or
STITCH_STICH
the genetic map file is correctly loaded in these software but emission matrix computation sometimes crash with really null genetic distance, due to bad check by the softwares.
n
Also, at least to me, if this a centromere problem, this region probably should not be taken into account in any case, and whether you then assume a linear increase from the start, to end+1 or a flat from start to end and then linear increase from end to end+1 seems kind of irrelevant
👍 1
I am not an expert on the software used though
bad check by the software
one of the more common issues ;)