search

legumeinfo / ZZBrowse

Other
1 stars 1 forks source link

Handle macrosynteny events from Genome Context Viewer #26

Closed svengato closed 3 years ago

svengato commented 3 years ago

ZZBrowse currently handles these as follows (in the Chromosome view):

Macro-synteny row selection: Select the relevant chromosome.

Macro-synteny block selection: Adjust the organism 1 window to match the block reference, and the organism 2 window to match the block source. But (if I understand correctly) we would like to highlight selected blocks in the Whole Genome view.

adf-ncgr commented 3 years ago

I may be confused but are you saying that ZZBrowse already does something with macrosynteny? I mean via service calls and not broadcast channel events...

svengato commented 3 years ago

No, I thought we were talking about Broadcast Channel events. Now I get it. It sounds like what we want is a Services API (v2) compute-syntenic-blocks call from the Whole Genome view.

Compute Syntenic Blocks Takes a reference chromosome as an ordered list of gene families, and optionally a set of target chromosomes, and returns synteny blocks computed between the provided chromosome and each of the target chromosomes. If no target chromosomes were specified, then synteny blocks are computed for all chromosomes in the database.

svengato commented 3 years ago

I guess we should replace the v1 micro-synteny functions with their v2 equivalent as well?

adf-ncgr commented 3 years ago

I thought you already had v2 micro-connectivity worked out on some branch- or are you just saying we should make it official?

adf-ncgr commented 3 years ago

also, I probably should have noted that I had been imagining we could just send the chromosomes as identifiers, not necessarily requiring that we first call the relevant service ("chromosome" IIRC) to get each of species 1 chromosomes as an ordered list of gene families and then requesting macro blocks against the set of target chromosomes (ie species 2 chromosomes). But, beyond not being currently supported by the API, that might cut us off from "true federation" which is I think the reason it is currently structured the way it is (ie get the chromosome representations from service endpoint X which knows about species 1, them ask endpoint Y which knows about species 2 to do the block computations). So, perhaps better to approach it as is, unless it causes some issues.

svengato commented 3 years ago

We might as well make the v2 micro-synteny code official. However, it is almost a year old and does not agree with the (even older) Services API documentation. I need to test it again and should run it past Alan in case anything has changed.

svengato commented 3 years ago

I created a dev-macrosynteny branch for testing (currently the version running on fisher).

svengato commented 3 years ago

It often fails to return blocks for a few species 1 chromosomes, due to the GCV pairwise-blocks service not being able to handle nearly simultaneous multiple requests. Adding a time delay between requests (even up to 500 msec) does not help much, and of course slows it down.

To do: switch to GCV microservices which may help.

svengato commented 3 years ago

This was confusing - continued in #30.