Migrating one version of an assembly to another.

[rskr]

It seems that as methods improve, and more data is collected migrating an older version of an assembly to a newer version can become necessary, assuming that an assembly has been adopted and manually annotated with experiments. I am wondering what the existing strategies are for doing this?

[SES]

There is a LiftOver tool from UCSC for that (I recall that the same tool may be available from Galaxy).

[rskr]

There is a LiftOver tool from UCSC for that (I recall that the same tool may be available from Galaxy).

I am more interested in how they generate the liftOver coordinates than the liftOver itself, and there is some documentation of that.

Also are there any other strategies out there. UCSC sites GRIMM, which seems a little naive.

[SES]

I am more interested in how they generate the liftOver coordinates than the liftOver itself, and there is some documentation of that.

Also are there any other strategies out there. UCSC sites GRIMM, which seems a little naive.

I am not sure what you are asking. The LiftOver tool converts coordinates and annotations from one assembly to another. You are only interested in how it's done? If that is your question I would say look at the code for the Galaxy Lift-Over tool or LiftOver from UCSC.

[rskr]

I am more interested in the generating of the coordinates themselves(which there are also pipelines for at UCSC), rather than the conversion, which appears to be an academic parsing problem.

[SES]

So you are not actually interested in the coordinates? Sorry but it's not clear what you are trying to do.

[rskr]

So you are not actually interested in the coordinates? Sorry but it's not clear what you are trying to do.

I am trying to calculate the transformation from one assembly to another, as it is they have names and contigs that are similar, but in no particular order, and probably fragments of each contig that are in different orders and orientations. One of which probably has annotations that can't be simply reannotated, and not lost. With most of the manually curated genomes it is easy as modifications are made a list is kept, however for automatic builds this can get complicated. Once that is done lifting over ought to be easy.

[SES]

Okay, I thought you were dealing with an annotation file but it sounds like you are talking about comparing actual assemblies. If you are not trying to combine the assemblies but just find where the annotations are in the second assembly, why not just use vmatch or MUMmer to see where the contigs from assembly 1 are in assembly 2. The annotation coordinates would change but they would not get lost because you can easily keep track of where every contig matches.

[rskr]

Okay, I thought you were dealing with an annotation file but it sounds like you are talking about comparing actual assemblies. If you are not trying to combine the assemblies but just find where the annotations are in the second assembly, why not just use vmatch or MUMmer to see where the contigs from assembly 1 are in assembly 2. The annotation coordinates would change but they would not get lost because you can easily keep track of where every contig matches.

Vmatch is suffix array based too!

[SES]

Vmatch is suffix array based too!

Yes! I believe that MUMmer actually shares the same design, and it was implemented by the author of Vmatch.

[rskr]

Mauve and mauveAlign, so close yet so far away. The paper looked pretty good, but then the implementation concatenates all the sequences together from each genome before it does the alignment. Sigh