Upgrading syri

[mnshgl0110]

We are working towards upgrading syri. The idea is to increase the usability of syri by removing some of its current limitations while adding features required for the most advanced analysis. Specifically, we are starting with three major goals.

1. Allow inter-species comparison
2. Perform structural analysis of multiple genomes
3. Provide outputs in different formats suitable for various analysis (for ex: output translocation for studies focusing on whole-genome analysis and output the same variation as insertion + deletion when the focus is on local variation)

Here, I would like to invite the users to share your ideas about you would like syri to do.

Is there anything that you think can be improved? Something that bothers you? Something that you would like to have? Something that you think would be useful in the future? Something that should not be changed?

All suggestions and opinions are welcome.

[wrengs]

Hi Manish,

Love to see that you are pushing forward with this!

Perhaps to get some ideas (or discussion) started:
1. I guess this might be somewhat dependent on the ability of aligning the genomes of the species, which in turn is partly biased to the aligner and/or settings. Recently, I noticed that there is quite some difference in D-genies output when using different minimap2 version (i believe it was 2.11 versus 2.26). In our specific case, v2.11 output even made more sense and I am happy to show you the examples in a brief meeting. Nevertheless, I am wondering whether it has been checked if different aligner versions affect the capability of SyRI in a way also.

2. By structural analysis of multiple genomes, you mean comparison of two or more genomes directly with one another rather than one after another as currently is the case?

3. 1) A potential suggestion here is the possibility of having a non static plot allowing to zoom / explore variation, e.g. .html or .svg format.
Let's say you are comparing chromosomes of 2 species and on the chromosome wide level you get a plot whereby the biggest variants are annotated. However, you would like to move and zoom into a region of interest which appears relatively syntenic on a chromosome wide level. Then by zooming in, you see smaller inversions or variants starting to appear.
2) Another potential output feature might be a way to choose how to aligning the plot, which could help highlight for a certain feature (similar to aligning text in a word document, e.g. align left, center or right). See example below where everything is sort of aligned on the right end side (RGA2), showing

note that I could not find how exactly they generated this plot, but it comes from the following publication https://www.nature.com/articles/s41588-023-01589-3#Sec25

All the best,
Willem

[mnshgl0110]

1. Minimap2 changed the default parameters to allow for longer indels. IMO, this would work better for human like genomes, but the alignments become less sensitive affecting plant genome comparisons (note: plant genomes are often richer in rearrangements compared to humans).
   We have seen some differences in SRs called by syri using alignments from different tools. Indeed, it will be excellent to get the effects of different aligners and parameters on SRs called in genomes of different complexities.

2. Comparing multiple genomes simultaneously would be the end goal, but is quite challenging to achieve (even at the theoretical level). During resequencing analysis, it is straight-forward to say that a particular reference position has same mutated allele in some of the query genomes. During assembly comparisons, it is possible that the mutated alleles are at different coordinates in the query genomes. So, the joint-variant calling need to consider both reference and query coordinates, and this is non-trivial. So, although we pursue that, we are also considering some intermediate strategies where pairwise comparisons are merged using the conserved synteny as the genomic backbone.

3. Similarly, getting dynamic visualisation is a tricky (and time consuming) goal to get. The idea to customize alignments is quite interesting, but I wonder how it would work at the genomic level where there are no obvious anchor points (like the start codon here). In case you have given this some more thought on this, then it would be great to see some sample drawings.

[PouyaMotieNoparvar]

Hi, during the installation of Syri i encountered many issues due to incompatibality which could be solved easily. I strongly suggest to remove the lines in .cpp files (i.e. inversions.cpp & tdfunc.cpp) containing "PY_MAJOR_VERSION = __Pyx_PyInt_As_int(o);" because you should avoid direct assignment to PY_MAJOR_VERSION. Instead of directly assigning a value to PY_MAJOR_VERSION, you should avoid modifying it directly. If the package code is trying to change the Python major version at runtime, it's likely not a good practice and should be re-evaluated. I hope this is useful for upgrading or at least for users.
Bests,
Pouya

[lrauschning]

Hi Pouya,
the .cpp files of syri are build intermediates that are autogenerated by Cython. The issue with PY_MAJOR_VERSION should have been fixed in cython/cython#4927 – otherwise you can also try pinning Cython to 0.29.
If there are other build or runtime issues with syri feel free to open an issue at the github page!
Best,
Leon

[mparker2]

Hi Manish,

Re. copy number calls and indels identified between adjacent overlapping alignments, the current implementation of these with mutual exclusivity does not make sense in my opinion due to the information loss. The current default offset parameter means that a 10kb insertion can be thrown away because of a 6bp micro-homologous duplication. I have a couple of suggestions of how this issue could be resolved...

1. Get rid of the CPG/CPL calls entirely and just represent all these cases as left aligned indels including both the unaligned indel and the duplicated microhomology.
2. Represent all these cases as left aligned indels as in suggestion 1, but add CPG/CPLs as child records of the Indels to show which part of the insertion or deletion is duplicated/deduplicated.
3. Keep the current implementation, but change the implementation of the indels so that they include the duplicated sequence and are left-aligned. Then users could set --offset arbitrarily high to achieve the same result as suggestion 1.

What do you think? I am happy to help with the implementation of this in any way I can

[fergsc]

Could syri output be extended such that each alignment contains a similarity score?
If using mummer this information could be found with a little work, however with sam/bam/paf files this is more complex.
We could then better filter our ouput based on the biology and not a fixed 90%. Additionally, the similarity score could be very inofrmative on SV age, selective pressure, etc.

[mnshgl0110]

Yes, this should be possible. Even for BAM/PAF files, syri does calculate alignment identity using the CIGAR string, so the information is already there.

In VCF files, this should be straightforward. In the syri.out file, this would be tricky as the file-format currently does not have a "free column" where new information can be added. Syri can output an additional file with the alignment scores, but I guess that would decrease the usability (filtering based on two files would be trickier). Nevertheless, this is a useful idea and worth implementing.

@lrauschning We should consider this for msyd as well.

[lrauschning]

Heya @fergsc,
msyd currently outputs this info when exporting synteny calls to VCF. In PFF, it is not reported but could in principle be extracted from the full cigar string.
I think what makes the most sense is to have a separate python script that outputs this information given a syri output file and corresponding alignment – that way, SyRI output doesn't need to change, and the script can be more easily adapted (might make sense to also have it report distances according to some evolutionary models). I think the script could be distributed/installed along with SyRI, but might also make sense to have it integrated in SyRI and running only when exporting as VCF.
Using the msyd API, this should be fairly straightforward I think. The syri output can be read with io.extract_syri_regions, then matching the syri regions to alignments with pansyn.match_synal (similar to how its done here) and calling get_identity on the cigars in the Pansyn object. I think this would also work on syri annotations other than SYNAL, though I haven't tested the code for this.

[fergsc]

Having it as an external script would be fine, and at a minimum outputting the unique syri ID and score. The idea would be to append a similarity score to all events so that I can examine their distributions and use syri to examine genomes over a range of evolutionary distances/between populations/etc.

Also for NOTAL regions, when using the auto filter, syri will report higly diverged regions as NOTAL. If there is a low identity alignement it would get included with insertions/deletions. But with an identity score we can better determine what they are.

[fergsc]

Hi Manish,

We have been doing some population level SV calling with syri and are trying to create a merged vcf from all samples. Given the requirements of a vcf and for identifying common SVs we are interpreting our data relative to a common reference.
ie. Ref vs Qry1, Ref vs Qry2, Ref vs Qry3, etc.

In the case of NOTALs within the query genome we would have an entry in the vcf for an INS and a location where it is inserted. To get a location (POS field in vcf) we are going to try to trace the qry NOTAL breakpoints back to their reciprocal location in the ref genome

eg.

giving a vcf such as:

#CHROM POS ID REF ALT QUAL FILTER INFO FORMAT sample
Ref x INS1 N seq/<INS> . PASS SVTYPE;SVLEN;ChrB;StartB;EndB SVTYPE=INS;SVLEN=999;ChrB=Qry;StartB=a;EndB=b

The same idea carries over to TRANS (where we want to know the start and end breakpoints in the Ref, and also the insertion point in terms of the Ref). DUPs are also challenging and need to be assessed and recorded differently if the copy gain is in the qry or ref genomes.

It would be fantastic if future syri could, when possible, incorporate some of this.