-
Notifications
You must be signed in to change notification settings - Fork 384
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
Batch script problems #44
Comments
My batch job that I started yesterday was only able to do 48 gotos/snapshots in the 5 hours I'd requested on the node before it got kicked off. When I run the same script in 2.0.3, it finishes in a matter of minutes. Does 2.3.3 use a lot more memory? Maybe I'm hitting swap space. |
We have become aware of issues with batch scripts in version 2.3.3. We are working on the problem, in the meantime I suggest you continue to use 2.0.3 |
Well, I wish I could, but my current workflow requires that all the coverage plots have the same data range and I can't get that to work in 2.0.3. Setting the data range via the script (or via the GUI) does work in 2.3.3 and the setting keeps from position to position (which is great). It just takes much much longer. I timed the drawing of one of my 6 coverage tracks and it took roughly 25 seconds. Of course, it does that for each track and then wipes out and redraws all the tracks over again (at least 6 times over the one time I just sat and watched it go). Good luck with the fix! |
I have discovered that the slowness relates to using IGV via x11. I'd found a similar post from someone transitioning from version 2.1.x to 2.2.1. In their case, all they had to do was turn off anti-aliasing and it returned to its previous peppiness. Such was not the case for me. It still went excruciatingly slow (about 15 minutes for each snapshot, whereas version 2.0.3 did it in a second or 2). Even clicking menus caused a 5-15 second wait. So I started using a "vis node" on our cluster that's souped up for visualization and is utilized via some sort of fancy VNC. I'm running my scripts on that now and it's taking a few second for each snapshot - still not as fast as 2.0.3, but workable. |
Thanks for the updates. Both the IGV programmers happen to be out of the office right now, but addressing problems with batch scripts is definitely a high priority for us. |
Hi. I run IGV on a cluster using an interactive node with X11 forwarding on my Mac. It is running slowly and for each snapshot I have to wait and watch the screen redraw about 3 times. I am trying to take hundreds of snapshots and this is running excruciatingly slowly. Has this issue not been addressed yet? I see that these posts are from over 9 months ago. I can't run an older version of IGV, which works quickly, because I am running into this problem: https://groups.google.com/forum/#!msg/igv-help/5NaVpKNVbB8/ZXTuh9Lp0ssJ Any help would be greatly appreciated. |
Hi, its difficult for us to fix problems we can't reproduce. If you could provide some profiling information or otherwise pinpoint what is causing the issue it would help. As an alternative, have you tried using a VNC or other configuration to avoid the X11 forwarding? |
Another suggestion, could you try disabling antialiasing? You can do this from the UI, select "View > Preferences" and click the Advanced tab. Uncheck the "Enable antialiasing" box. |
Thanks for your reply. I'm not exactly sure what profiling information would be helpful to you. There are no error messages to provide, it is just running very slow. I can provide my script, which basically loads three exomes at a time, goes to a specific location, and takes two snapshots (one with expanded tracks and one collapsed), then the process is repeated for a new set of three exomes. I am running IGV on a computer cluster (HMS Orchestra) in an interactive node with 10GB of maximum memory. I launch IGV with the following command:
I use X11 forwarding on my Mac with XQuartz 2.7.5 (latest version). My Mac has 20GB of memory. I do not believe we have VNC, but I will look into it. Any other suggestions? Thanks so much. |
Closing this issue. I do have not additional suggestions for running over X11, and unfortunately its not something we can support with the resources we have. |
So I discovered this problem after finding a work-around for the coverage track height issue I submitted yesterday. Running the same batch script in version 2.0.3 and 2.3.3 runs really fast in 2.0.3, but in 2.3.3, it takes a really long time. I watched it for minutes redraw the same data 6 times before performing the snap shot. I would watch the window clear out to be almost completely blank (other than the pane borders) and then watch the data get redrawn slowly from bottom to top, left to right - then clear out again and redraw the same position, same data, same exact overall image 5 more times, bottom to top, left to right. In version 2.0.3, all the data appears instantaneously. Once. Then it takes the snapshot. Here's the batch script:
snapshotDirectory /panfs/panfs.ccr.buffalo.edu/projects/ccrstaff/rwleach/PROJECT/CRPC/MACS/snapshots
goto chr10:73150690-73162690
setDataRange 0,40
snapshot CDH23.chr10.73151690-73161690.png
goto chr10:73549527-73561527
snapshot CDH23.tss2.chr10.73550527-73560527.png
goto chr10:73565639-73577639
snapshot CDH23.tss3.chr10.73566639-73576639.png
goto chr1:12117433-12129433
snapshot TNFRSF8.chr1.12118433-12128433.png
In the time it takes 2.3.3 to do this test portion of data, I can screen cap about 100 positions in version 2.0.3. Why does it draw each position's data 6 times, slowly? Is there a way I can alleviate this myself?
Thanks,
Rob
PS - Separate issue: when a slightly different script is launched via the command line, the whole thing hangs and seemingly gets stuck. Here' the head of the other script:
new
load /projects/ccrstaff/rwleach/PROJECT/CRPC/MACS/LNCaPDHT-LNCaP-datarange40.xml
snapshotDirectory /panfs/panfs.ccr.buffalo.edu/projects/ccrstaff/rwleach/PROJECT/CRPC/MACS/LNCaPDHT-LNCaP-datarange40.xml.snapshots/hg19_SimpleTxStartCoords20130226-strand.txt.pad20k.forigv10k.uniq.igv-dir
goto chr10:73150690-73162690
snapshot CDH23.chr10.73151690-73161690.png
goto chr10:73549527-73561527
snapshot CDH23.tss2.chr10.73550527-73560527.png
goto chr10:73565639-73577639
snapshot CDH23.tss3.chr10.73566639-73576639.png
goto chr1:12117433-12129433
The text was updated successfully, but these errors were encountered: