Understanding aln-r2 output

[Pkaps25]

Hi,

Attached is a *.rawLR.pred file from one of the samples with SRS data I used to create my RPGG. Maybe I am not fully understanding this output, but if the ground truth k-mer counts are identical to the SRS k-mer counts at a given locus, wouldn't we expect the corresponding r^2 value to be closer to 1? In the cases where the k-mer counts are equal, the r^2 value is always 0.

[joyeuxnoel8]

Ah right, this is because all the kmer counts in the assembly e.g. tb_south_am have the same value. The output r^2 will always be 0 in this case. Nonetheless, it's possible to prevent this by adding a dummy variable at (0,0) since the intercept term should always be 0 in this context. I'll update the code shortly so that it makes more sense to have a value closer to 1 instead of 0.

[joyeuxnoel8]

script/kmers.linreg.py is now updated!

[Pkaps25]

Great! Thank you so much for your help. I would like to ask about the result of aligning SRS reads to an RPGG. Could you explain how to interpret the *.tr.kmers file that results from aligning to the graph? Is it possible to use this file directly to differentiate the VNTR composition of samples, perhaps by comparing the kmer counts at the various VNTR loci?

[joyeuxnoel8]

Comparing the kmer counts at the same locus across samples are valid when:

• If SRS datasets are coming from the same batch and sequencing technology --> valid
• else
  • if SRS datasets have similar sampling biases (check here for details) --> valid
  • else --> invalid

Comparing the kmer counts between loci across samples are most likely invalid, unless the two loci have similar sampling biases.

When analyzing the 1KGP and GTEx samples in the manuscript, we also had to impose this constraint and remove outliers with distinct sampling biases.

[joyeuxnoel8]

It seems that you have sorted things out. But just to make sure the usage is clear: the leave-one-out (LOO) analysis is meant to evaluate the performance/quality of an RPGG by checking how accurate the length estimates are, assuming that the set of SRS samples used have similar LSBs. The LSB analysis allows us to evaluate whether the assumption holds, which is a necessary requirement for length prediction and therefore LOO analysis. And yes the bed file for non-repetitive regions is also released under v1.0 <https://github.com/ChaissonLab/danbing-tk/releases/tag/v1.0>.

…

On Fri, Jan 29, 2021 at 12:31 PM Pkaps25 ***@***.***> wrote: I understand the methodology behind the LOO analysis. After running the snakemake file for LOO, how do I incorporate the output into determining if the LSB for my samples are similar? Is this analysis only to ensure that the sample biases of the data form distinct clusters? Also, as I understand it, I need to define a set of control non-repetitive regions and run the getCovByLocus.397.sh script to obtain coverage stats for each region. I can then use LSB_analysis.ipynb to obtain an LSB.tsv file for my data for length prediction. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/ChaissonLab/danbing-tk/discussions/5*discussioncomment-322003__;Iw!!LIr3w8kk_Xxm!9wxtBvxGa0yhY8goZEBE3chpgRdY6xP-Gzf9Y192ymbBgDRLi-GqDmItoK-s-bA$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AF4XDRA45QJKADYPRKM6TC3S4MLKHANCNFSM4WK3HVHA__;!!LIr3w8kk_Xxm!9wxtBvxGa0yhY8goZEBE3chpgRdY6xP-Gzf9Y192ymbBgDRLi-GqDmItTQGYtxY$> .

[joyeuxnoel8]

Also, params.FS is now the size of flanking sequences. Thanks for the catch!

[Pkaps25]

Thank you, running successfully now.

[Pkaps25]

Hi, I am receiving a different error in the JointTRAnnotation rule, I think when merging regions across haplotypes. I have merged overlapping TR regions prior to running and have attached the trace. Let me know what other information may be helpful.
15klog.txt

[Pkaps25]

Resolved: Problem was using an old Snakefile where FS was hardcoded and did not match the FS in config file.

[joyeuxnoel8]

Nice, thanks for the update!