Issue #13: FACS file parsing breaking #14
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is to address issue #13.
Initially, it seemed like the issue was that, given a FACS file, Ginkgo could only pick a CN multiplier within [1.5, 6], even though a cell was marked as e.g. ploidy 1.3. However, looking more closely at the code, the multiplier is correctly set by the FACS file regardless of its value.
So Ginkgo's CN calculation works fine; where it breaks is when it tries to plot the SoS error plot; this is where it assumes the CN multiplier is within [1.5, 6], so this PR updates that SoS plot such that it shows:
cc: @jpritt: I sent you an invite to become a collaborator on this repo so that I can add you as a reviewer
Sample output (with FACS file):
Sample output (without FACS file):
(hg19.T1 is the cell that currently fails in Ginkgo)