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

Check mutation type against tree #709

Merged
merged 3 commits into from
Mar 11, 2019
Merged

Check mutation type against tree #709

merged 3 commits into from
Mar 11, 2019

Conversation

jameshadfield
Copy link
Member

@jameshadfield jameshadfield commented Feb 27, 2019

This PR sets mutType intelligently according to what mutations are available on the tree. Furthermore, it allows nuc-genotype colorBy values for datasets lacking gene annotations in the metadata JSON.

Tested against a number of datasets with no regressions seen, but @emmahodcroft please try on a few more! Please note that any d3-transition errors encountered are unrelated to this -- see #708. Update: Rebased onto v1.36.1 so that there should be no install / d3-related errors.

@tsibley may care to examine d34c075.

Previously we assumed that  aa mutations were present and defaulted to this (currently unable to be changed by the URL query). This commit checks the default mutType ("aa") against the nodes, falling back to "nuc" if available, or "null" if neither are present. 
Additionally, we now collect available node attrs across all nodes, not just the root node, which results in an increased and more accurate set of attrs. 
Performance penalty on my laptop: 1-3ms.
rendering function names changed to improve clarity
If no annotations are provided, the default geneLength object is `{}` which shouldn't be validated against. This commit changes decodeColorByGenotype to only validates against objects with keys.
@tsibley
Copy link
Member

tsibley commented Feb 27, 2019

@jameshadfield Thanks for these fixes! I'm not sure I see where the default geneLength passed to decodeColorByGenotype is {}. Can you point that out to me?

It seems like at the very least there should be a nuc key in any geneLength passed to decodeColorByGenotype?

@jameshadfield
Copy link
Member Author

jameshadfield commented Feb 28, 2019

I'm not sure I see where the default geneLength passed to decodeColorByGenotype is {}. Can you point that out to me?

https://github.com/nextstrain/auspice/blob/master/src/reducers/controls.js#L38

It seems like at the very least there should be a nuc key in any geneLength passed to decodeColorByGenotype?

Not if annotations aren't defined in the metadata json.

Copy link
Member

@emmahodcroft emmahodcroft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jameshadfield ! I only have two datasets like this, but this fix seems to work for them both - mutations displaying on hover as expected, and able to colour by nuc position.
Thank again!

@tsibley
Copy link
Member

tsibley commented Feb 28, 2019

Not if annotations aren't defined in the metadata json.

Ah, I see. I was thinking auspice could/did compute the nucleotide length itself.

@trvrb
Copy link
Member

trvrb commented Mar 11, 2019

I'm going to go ahead and merge this. Going on Emma's specific feature testing and I can't find any regressions.

@trvrb trvrb merged commit 2bfe1dc into master Mar 11, 2019
@trvrb trvrb deleted the muttype branch March 11, 2019 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants