Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Genes disappear from LD plot at certain plot widths #160

Closed
jstewart-ebi opened this issue Mar 4, 2020 · 7 comments
Closed

Genes disappear from LD plot at certain plot widths #160

jstewart-ebi opened this issue Mar 4, 2020 · 7 comments
Labels
Type: Bug Something isn't working

Comments

@jstewart-ebi
Copy link
Contributor

@ljwh2 commented on Mon Mar 02 2020

Daniel reported a bug with the LD plot. Genes that are visible in the 50kbp window disappear in the 25 and sometimes 200kbp window (genes displayed in track "Ensembl genes", below the plot; plot width changed using the drop-down on top right of the plot). I replicated the behaviour with a couple of other variants. As Daniel observes, it seems to occur when the gene is larger than the initial plot width:

https://www.ebi.ac.uk/gwas/variants/rs6466479
https://www.ebi.ac.uk/gwas/variants/rs45446698

but not

https://www.ebi.ac.uk/gwas/variants/rs7412

This is misleading for users and needs fixing so the genes are visible at all window sizes.

Original GWAS-info email:
I wanted to show off with the LD plot and I have bumped into a bug. Check out this variant: https://www.ebi.ac.uk/gwas/variants/rs35407685

This variant is an intron variant (https://www.ensembl.org/Homo_sapiens/Variation/Mappings?db=core;r=7:140785945-140786947;v=rs35407685;vdb=variation;vf=20866875) overlapping with BRAF. When the LD plot is loaded the BRAF gene on the reverse strand is correctly displayed (50kb window by default). However it disappears when the window size is decreased to 25kb, and when you try to change back to 50kb it still not shown, only when the largest 500kbp window is selected.

I think when the plot is updated only those genes are shown, whose start and end coordinates are both included within the window. So I suspect the fix could not be too complicated.
Please take a look and verify if this indeed not the expected behavior.

@jstewart-ebi
Copy link
Contributor Author

Ugh. I've been watching what's going on and I think I've got an idea. When the plot_width changes, it needs to reload the data. I think this is block of code causing the problem:
`
var preloadedData = self.getPreloadedData('gene');

  if(preloadedData){

    if(self.configuration.region_width == '500'){
      self.data.four = preloadedData;
      return;
    }

    self.data.four = preloadedData.filter( entry => {
      return self.data.left < entry.start && entry.end < self.data.right;
    })
    return;
  }

That's saying 'if there is preloaded data, check against the region_size. If the region_size is 500, return all the data. Else, only return the data contained in the region. Like Daniel thought, this is cutting out genes that aren't contained in the region window. Changing
return self.data.left < entry.start && entry.end < self.data.right;
to
return self.data.left < entry.start || entry.end < self.data.right;
`
should return any related genes.
sending this to Daniel for investigation.

@DSuveges
Copy link
Contributor

DSuveges commented Mar 4, 2020

@jstewart-ebi that's right! If either the self.data.left < entry.start or entry.end < self.data.right are true, the feature will not be displayed. So if the gene start or the end is outside the window, the gene will not be shown. This might effect a great handful of genes (depending on the window size).

What I find interesting though is that the initial loading of the page works... It only fails when the page is reloaded. Strange.

We rather need something like this (you can easily try if it works):

self.data.left < entry.end && entry.start < self.data.right;

But I'm quite sure the guy will fix it in no time.

@jstewart-ebi
Copy link
Contributor Author

There may be another bug with the way the data is loaded. In that same block of code, if there's no preloadedData, it queries the /overlap/region endpoint, but uses data.left and data.right, not data.maxLeft and data.maxRight, so the preloaded data will only be a 200kb region, not a 500kb one.

@DSuveges
Copy link
Contributor

DSuveges commented Mar 5, 2020

Well that's interesting. Do they have the repo on github somewhere?

@jstewart-ebi
Copy link
Contributor Author

I'm not sure. There is an Ensembl repo for widgets https://github.com/Ensembl/public-plugins, but I can't find the LDPlot.full.js file in the Ensembl repo.

@msmanoj
Copy link

msmanoj commented Apr 28, 2020

Hello @jstewart-ebi & @daniwelter, thank you reporting this issue and investigating this further.
I have now updated the condition to the following and pushed it live:

self.data.left < entry.end && entry.start < self.data.right;

There may be another bug with the way the data is loaded. In that same block of code, if there's no preloadedData, it queries the /overlap/region endpoint, but uses data.left and data.right, not data.maxLeft and data.maxRight, so the preloaded data will only be a 200kb region, not a 500kb one.

The way it works is that it first loads the data for the initial value selected in the plot width drop down (50Kb for example) and uses it to draw the UI. Simultaneously, it also sends another request in the background to preload the data for 500Kb which is just to make the transition pretty instant when we increase the size from 50Kb to 200Kb or 500Kb, instead of having to wait longer.
OTOH if you already have 500Kb selected during the initial load, it would mean that data.left = data.maxLeft & data.right = data.maxRight, in which case the second request not made.

I hope that makes sense. Please let us know if you come across any other issues.

Kind regards,
Manoj

@jstewart-ebi
Copy link
Contributor Author

Fixed by Ensembl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants