-
Notifications
You must be signed in to change notification settings - Fork 379
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
Ultima develop code merge #1423
Conversation
Ultima IGV Extensions ported and refactored as extensions WithJava added Update gradle.yml Update gradle.yml Update gradle.yml Update gradle.yml Update gradle.yml Update gradle.yml Update gradle.yml Update gradle.yml t0 handling guard against t0 missing t0 processing corrected should only apply to del of a single base and only when the deleted base is different from the two bases surrounding it. Otherwise, previous logic should be applied (now restored) update token M1 build added
@jrobinso - this is the PR related to #1393. Can you suggest how to move forward with that? I am also attaching the documentation of the changes: |
@ilyasoifer Apologies for the delay, I am on vacation returning Nov 19. Will respond further via email. |
WRT to next steps, we will need a test case we can explore ourselves. Also, eventually we would request the documentation in Markdown, as that is the language used for our documentation system (https://igv.org/doc/desktop/). Thanks. |
@jrobinso - thanks for the feedback. We will add the test data (I assume to |
flow_renderer.sam added to test/data/sam. Once @ilyasoifer adds doc we can point to specific reads & locations for each new feature. Data is around chr1:10000 |
@ilyasoifer Our new doc repo is not yet public, but here are some sample markdown files from the User Guide > Tracks and Data Types > Alignments. Let me know if you have any questions. |
@ilyasoifer The IGV doc repo is now public at https://github.com/igvteam/igv-docs-website |
Thanks @helgathorv for these examples. Should we create a PR for the documentation in that repository or attach it to this PR? |
@ilyasoifer As this is just a single page of doc attaching it here is fine. |
@jrobinso and @helgathorv I added to this PR a folder called |
@dror27 - I think our code contains a small bug similar to what we encountered in broadinstitute/gatk#8337. |
Logic added to screen flow alignments based on read-group presence and fields |
Hi all, apologies for the lack of response, I've been delayed by travel and some pressing issues but will get to it ASAP. |
Hi all, I might have missed but have instructions for use been posted somewhere? The documentation describes the visual features but how do we actually try it? BTW the doc pages have been added to the igv-docs-website, any further changes to docs should be done there. Currently the page is at https://github.com/igvteam/igv-docs-website/tree/main/igv-docs/docs/UserGuide/tracks/alignments/ultima. I'm concerned about this new (to IGV) concept of "extensions". Its not part of our current design, obviously, and I am not sure we want to take on a new concept such as this for the sake of a few visiual enhancements for data from a specific vendor. It might be a good concept, that we would consider as part of a major refactor, but is it required for the enhancements we are considering here? |
@jrobinso - as to the choice of implementing this visual feature using an extension modality - this has mainly been done as a the feature was developed over the past year or two - while IGV versions were moving on. The extension model allowed for isolating the code for the new visual feature into a separate set of classes, with minimal changes in IGV itself. This allowed updating the core IGV and tacking on it the visual extension. This might not be required when the features are accepted as being part of the core IGV. Still, I can envision that some IGV users/developers might find it easier to use this extension mechanism to create new visualizations which would start as experimental and wind up in the general version. The bottom line is that you - as the product's architects - need to take a decision. We will probably go with what ever you decide. As to the doc, @ilyasoifer will respond. |
@jrobinso Data had been placed here: Thanks for moving the docs to the other repo, should we removed them from this PR?
|
@dror27 An extension framework might be a good idea in general, but we have then escalated this PR significantly. For one thing we would need documentation on the framework itself. Its an interesting idea but given constraints here it would be some time before we are able to consider it. If I understand this PR the changes, from a user perspective, amount to some additional visual elements for indels and some additions to the popup text. I would not expect this to require many changes to code, I think the bulk of changes here are for the extension framework. If you could remove that (the extension) it would certainly expedite review. The "ext" package might be renamed to "ultima" for specialized code that remains, similar to the "smrt" (pacbio) package. @ilyasoifer The doc can be removed from the PR, no requirement to do so, but if you wish to make changes let's do it with PRs to the doc website. |
@jrobinso ok. I will update. |
@jrobinso @ilyasoifer - I have now removed the framework (concept and code). Additionally, the package has been renamed to .ultima. Thank you for your input and review |
@dror27 Thanks for the quick turnaround, much easier to review now. I had left some comments on particular files prior to this, hopefully you can see them. I have not used the github review function before. 2 in particular, could you explain the changes to SessionWriter and LoadFromURLAction? I don't understand the SessionWriter change relevance, and am not sure about the "multiple tracks" addition either. LoadFromURLAction already supports loading multiple urls, what does this change allow? |
@jrobinso I was not able to see your individual comments, but I understand your concerns. The two changes mentioned (loading mutliple tracks and session-writer changes) were remains of behaviors of previous IGV versions that we patched over. They are no longer required and were therefore removed. |
@@ -1057,6 +1082,180 @@ private void drawLargeIndelLabel(Graphics2D g, boolean isInsertion, String label | |||
} | |||
} | |||
|
|||
private void drawInsertions(Rectangle rect, Alignment alignment, RenderContext context, AlignmentTrack.RenderOptions renderOptions, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a new method, most of it moved from somewhere else I think. The github diff tool here makes it hard to see what has actually changed, and what the consequence of this new method will be, but is it neccessary in the first place? Fewer changes are better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrobinso this method, drawInsertions, if I understand correctly, was authored outside the scope of this pull request (see Git Blame information).
I did notice that it, along with the following methods in this class (VariantRenderer) is not used. You may consider removing them:
- drawInsertions
- renderExpandedInsertion
- getOutlierStatus
- compareToBounds
Running "unused declarations" code analysis produces many more unused methods - so I think that this is a bigger issue and might not be related to this pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, could you remove this method? That will make for a cleaner merge. Also could you remove the doc as that has been moved to the igv doc repository? With this I think this will be ready to merge. Thanks for your prompt responses.
Done - method drawInsertions and superfluous doc removed. |
OK great! I will do a pull and some quick tests and then merge, probably this evening. Thanks for you quick responses, it makes this easier. |
Thanks again for your contributions. This is merged and will be part of the upcoming 3.0 release. We hope to publish a preview before the end of the year, with a final release early in 2024. If you would like to suggest a short description (1-2 sentences) for the release notes please feel free to do so here. Otherwise we will derive a description from the documentation. |
@jrobinso thank you for the joint work and for the merge. @ilyasoifer can you please suggest a short description (1-2 sentences) for the release notes? (we've removed the doc from the source tree). My take on summarizing the deleted doc:
|
@jrobinso - thanks for the efficient merge. I agree with @dror27 description for the release note, just one minor tweak:
|
@dror27 A problem has arose. We need a better test for "isFlow". The problem is "ti" and "tp" are not reserved tags, anyone can use these for any application and we now have non-Ultima data that uses "tp". So we need something more precise. Is there anything in the BAM header that would tell us this is a "flow" tagged file? Any other suggestions? Problem is reported here (or rather symptom): #1468
|
Thanks, we will take care of this, hopefully today.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Jim Robinson ***@***.***>
Sent: Tuesday, January 23, 2024 6:11:41 AM
To: igvteam/igv ***@***.***>
Cc: Ilya Soifer ***@***.***>; Mention ***@***.***>
Subject: Re: [igvteam/igv] Ultima develop code merge (PR #1423)
@dror27<https://github.com/dror27> A problem has arose. We need a better test for "isFlow". The problem is "ti" and "tp" are not reserved tags, anyone can use these for any application and we now have non-Ultima data that uses "tp". So we need something more precise. Is there anything in the BAM header that would tell us this is a "flow" tagged file? Any other suggestions?
Problem is reported here (or rather symptom): #1468<#1468>
private boolean isFlow(SAMRecord record) {
// must have one of the key attributes
for ( String name : KEY_ATTR.split(",") ) {
if ( record.hasAttribute(name) ) {
return true;
}
}
return false;
}
—
Reply to this email directly, view it on GitHub<#1423 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGDPRCOLCD3YNQZBLJ3IBLLYP4Z73AVCNFSM6AAAAAA6UFUU4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBVGI3DAOJUHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
________________________________
CONFIDENTIALITY NOTICE: This message (including any attachments) should be presumed to contain confidential, proprietary, privileged and/or private information. Information contained in this message is intended only for the recipient(s) named above. Any disclosure, reproduction, distribution or other use of this message or any attachments by any unauthorized individual or entity is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete the message and any attachments. Learn more about Ultima Genomics’ Privacy Policy<https://www.ultimagenomics.com/privacy-policy>.
|
@ilyasoifer Thanks, I have some ideas too but I'll wait for your suggestions. If you branch its probably better to do so from branch "2.17", as opposed to main, but either will do. It will be merged to both. |
In newer IGV code, we also test for the "ULTIMA" value in the "PL" (platform) attribute of the associated read group, the presence for the "MC" (maxHmer) in the read group and finally the presence "tp" attribute on the record itself. Does it make sense?
|
@jrobinso and @ilyasoifer - please see new pull request to address: |
That looks pretty robust. I'm also going to add a try/catch for any future conflicts, but with this test I doubt they'll be any. |
This pull request includes Ultima Genomics code contributed to the public IGV version.
Code mainly has to do with additional rendering features for Flow Based tracks, specifically graphic indications of INDEL qualities.
NOTE: please hold on reviewing this pull request, pending out-of-bound communication,.