Closed monicacecilia closed 7 years ago
Assigning everyone because this is simply a 'discussion' and one of you may have the explanation I can't remember. Thank you in advance! :bowtie:
I see, where it updates it in real-time and then you can copy-paste.
That box doesn't really have much meaning when you are looking at multiple genomes. You can still put it in the search features, IDs box (though I have to fix the bug in #1555). It is a rewrite of that box as it is. I also removed the drop-down as it was less than useless.
From a UI-perspective, it feels a bit redundant since we have axes with start and stop everywhere, it is a dual-purpose entry and the functionality is not aware of either organisms or anything to do with projection.
I'm not opposed to it, but I think we need to think about it a bit as I don't think it really scales as a solution.
I see the updated box on the upper right, where you can enter the name of a genomic element (NOT features, please, change that, please, pretty please, I've only asked for this correction once this month, 10 times any other month) and find it if it has been indexed. That is still useful.
The bit about coordinates - I actually use them quite a bit when I am using more than one browser tab for the same organism, jumping back and forward, - they rather handy to have. I do miss that badly. It is not easy to navigate to a set of coordinates by simply looking at them on a map / bar of coordinates. If I am in Group 1.33 (for example), and I want to go to a specific location elsewhere in the same organism (e.g. Group16.4), and I wrote down the coordinates for that second location (as I always do in order to take note of every detail of every exon for every gene model), then the box is useful. Easier than trying to find a gene model by name.
Then, there are cases where you are exploring sequences that do not overlap any gene predictions - and coordinates is all you have. it is specially useful in these cases.
Could you please elaborate on this? "You can still put it in the search features, IDs box"
Do you mean to say I can write coordinates on that box and it will navigate to them?
In theory yes. Its just using the existing JBrowse lookup mechanism.
I mean, that is what it looks like its doing, but I know it probably won't switch scaffolds, so that is kind of limiting. That is part of the #1555 fix.
WRT to the text box content, can you create a ticket with the exact text you want in there?
WRT to the use-cases, we can take a look at those. This just brings up more questions that I don't have answered (and makes implementation problematic).
How do we imply a negative scaffold or do we care? What happens when we have multiple + start / stop? Do we need to imply folding at some point?
I mean, that is what it looks like its doing, but I know it probably won't switch scaffolds, so that is kind of limiting. That is part of the #1555 fix.
Got it.
WRT to the text box content, can you create a ticket with the exact text you want in there?
There it is. https://github.com/GMOD/Apollo/issues/1682
WRT to the use-cases, we can take a look at those. This just brings up more questions that I don't have answered (and makes implementation problematic).
Well, such is biology, I suppose.
How do we imply a negative scaffold or do we care?
I do not know whether I fully understand what you mean here. It has never mattered the orientation of the scaffold, I guess because we have never before been able to flip one. It should not care, I imagine, if the scaffold (assembly fragment) is still named the same? I should be able to enter a set of coordinates.
What happens when we have multiple + start / stop?
A scaffold can have multiple starts and stops? How?!! - In case you aren't catching my meaning, these coordinates are only to represent a region of the scaffold, not coordinates representing the 'start' and 'stop' of a genomic element.
Do we need to imply folding at some point?
Not necessary.
I think this is taken care of as part of #1625, which also fixes #1555.
Dear Authors,
I have an issue related to this one: I can see the search bar but it does not work: When I input chromosomal coordinates the view does not move into those. Nothing happens when I click "Go" see screenshot
I wonder if this has got something to do with the JBrowse version we are using (1.12.1)? The error messages in the console (see screenshot) are produced upon refreshing the view and no error is shown after clicking "Go".
I'll post here the contents of our application.properties:
app.grails.version=2.5.5 app.name=apollo app.servlet.version=3.0 app.version=2.1.1-SNAPSHOT
Best, Juhana K
Should be dots and not dashes:
NW_016908771.1:107673..165172 (57.5 Kb)
Nathan
On Nov 26, 2018, at 6:13 AM, kammoji notifications@github.com wrote:
Dear Authors,
I have an issue related to this one: I can see the search bar but it does not work: When I input chromosomal coordinates the view does not move into those. Nothing happens when I click "Go" see screenshot
https://user-images.githubusercontent.com/22050587/49019122-e0477280-f195-11e8-9193-b0356f539f32.png I wonder if this has got something to do with the JBrowse version we are using (1.12.1)? The error messages in the console (see screenshot) are produced upon refreshing the view and no error is shown after clicking "Go".
I'll post here the contents of our application.properties:
Grails Metadata file
Sat Apr 16 11:48:41 PDT 2016
app.grails.version=2.5.5 app.name=apollo app.servlet.version=3.0 app.version=2.1.1-SNAPSHOT
Best, Juhana K
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/GMOD/Apollo/issues/1678#issuecomment-441652208, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt2qvMuii99ALklaRxvN6fb2qTtlgaaks5uy_b9gaJpZM4OQSXv.
Dear Nathan,
Thanks for the swift reply. The dots didn't help. I tried this with another Apollo instance we run on the same server. This one is running JBrowse 1.12.4-dev. I tried with both dots and dashes. Here screenshot with dot's:
The "Go" button is active but greys out when clicked and nothing happens on the screen. No output in the console. I tested this with three different client computers and different browsers (Firefox & Google Chrome).
Sure enough, we could use also dashes in Apollo 2.0.4 successfully. I would like to test upgrading the JBrowse to the latest version if you see any sense in it?
Best, Juhana K
Hmm . . . . you can try upgrading to the latest version of JBrowse using this branch:
https://github.com/GMOD/Apollo/tree/jbrowse-1.15
If this fixes it let me know.
You can see from our demo site (demo@demo.com / demo) that this seems to work, but if it doesn't work for you let me know:
Dear Nathan,
Thank you. I will test this and saw the search already working in the demo:
Can I switch branches by simply typing
git branch jbrowse-1.15
and does this override what we have regarding jbrowse in our apollo.config.groovy ?
jbrowse { // git { // url= "https://github.com/GMOD/jbrowse" // tag = "1.12.1-release" // branch = "master" // alwaysPull = true // alwaysRecheck = true // } url { // always use dev for apollo url = "https://github.com/GMOD/jbrowse/releases/download/1.12.4-release/JBrowse-1.12.4-dev.zip" type ="zip" fileName = "JBrowse-1.12.4-dev" } plugins { WebApollo{ included = true } NeatHTMLFeatures{ included = true } NeatCanvasFeatures{ included = true } RegexSequenceSearch{ included = true } HideTrackLabels{ included = true } }
Or can we somehow upgrade jbrowse with the apollo-config.groovy ?
Best, Juhana K
It build is so differently, I would do a separate clone in a separate directory:
git clone https://github.com/GMOD/Apollo
cd Apollo
git branch jbrowse-1.15
git pull origin jbrowse-1.15 # should see lots of files here
# copy in apollo-config.groovy if you need to
./apollo deploy # or ./apollo run-local
You can check a few files to confirm that you have the right changes here:
@nathandunn I can't remember but I thought maybe this fix that I made that was backported onto 1.12.5-release might have been relevant? https://github.com/GMOD/jbrowse/commit/6879dd45b8583a6b6cc2e367cd7ea7af1cb9fd34
The maint/1.12.5-apollo branch I think contains this. Unless 1.15 does already work, then that is cool that would also contain that fix, but otherwise I thought that it is needed to port this fix and it looks like kammoji is using a 1.12.4 which might be unpatched for this bug
Dear Nathan,
Thank you. I did now exactly this. I also copied in our apollo-config.groovy (which holds our database settings):
The run-local fails with following output:
~$./apollo run-local 8022 Node Version: 9 Npm Version: 5 ERROR: There are no scenarios; must have at least one. Yarn Version: ./apollo: line 100: [: -lt: unary operator expected javac 1.8.0_181 found javac installed JDK 1.8 found: javac 1.8.0_181 Final JBrowse settings [url:[url:https://github.com/GMOD/jbrowse/releases/download/1.12.4-release/JBrowse-1.12.4-dev.zip, type:zip, fileName:JBrowse-1.12.4-dev], plugins:[WebApollo:[included:true], NeatHTMLFeatures:[included:true], NeatCanvasFeatures:[included:true], RegexSequenceSearch:[included:true], HideTrackLabels:[included:true]]] Final plugins [WebApollo:[included:true], RegexSequenceSearch:[included:true], HideTrackLabels:[included:true], NeatHTMLFeatures:[included:true], NeatCanvasFeatures:[included:true]] :installJBrowseWebOnly Cloning a new JBrowse installing [url:[url:https://github.com/GMOD/jbrowse/releases/download/1.12.4-release/JBrowse-1.12.4-dev.zip, type:zip, fileName:JBrowse-1.12.4-dev], plugins:[WebApollo:[included:true], NeatHTMLFeatures:[included:true], NeatCanvasFeatures:[included:true], RegexSequenceSearch:[included:true], HideTrackLabels:[included:true]]] ERROR: There are no scenarios; must have at least one. :installJBrowseWebOnly FAILED FAILURE: Build failed with an exception. * Where: Build file '/opt/test/Apollo/build.gradle' line: 426 * What went wrong: Execution failed for task ':installJBrowseWebOnly'. > Process 'command 'yarn'' finished with non-zero exit value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 14.384 secs ~$
I am unwilling to run ./apollo deploy since we ran into problems with our PostgreSQL database the previous time in 2016. Since that we have been successfully annotating using only the run-local mode
Thanks for the assistance. I will troubleshoot this more when I have time. For now, we will use a workaround to navigate in the target genome with the search bar disabled. It was good to communicate with you and Apollo has helped us so much!
Best, Juhana K
@kammoji you need to install yarn
npm install -g yarn
I updated the build for this to properly catch this error. Thanks for catching that.
I would like clarification on this issue. Perhaps it is a matter of refreshing my mind. What was the idea behind removing the search box that allows curators to navigate to a specific set of coordinates?
I am aware that I can share a specific location with the URL, BUT, in this case, I am trying to navigate to the exact region in the same genome, except they are in different servers, so I can't share one URL to access the other.
What was the rationale behind this change?