memory is low, reading terminating

[nkc]

I recently upgraded to Mac OS 10.8.3 and downloaded the 2 GB version of IGV 2.2. After viewing several different genes, I invariably get the above message. If i follow my "activity monitor" I can observe that the memory used by IGV increases with each new gene I view (starts at ~400 GB) and, expectedly, when I have 4 tracks it increases faster than when I have fewer tracks. Once the memory gets to 2 GB the the above message appears. I'm not a computer savvy user, but it seems to me that I should be able to clear out that memory used by the previous genes viewed (I really don't care about the "back" button, if that's why these things accumulate). 

Any advice? 

[Jim Robinson]

We will look into this,  you are correct in that memory from prevously viewed genes should be cleared (you shouldn't have to do anything).   So it would appear to be a bug in our software.   I'll post here when we have investigated.

Jim

[nkc]

Great. thanks. nkc

[Jacob Silterra]

Could you try the latest snapshot build at http://www.broadinstitute.org/software/igv/download_snapshot? We made some changes to how alignments were loaded, this may perform better. Let us know.

Thanks,

-Jacob

Great. thanks. nkc

--
 
---
You received this message because you are subscribed to the Google Groups "igv-help" group.
To unsubscribe from this group and stop receiving emails from it, send an email to igv-help+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jacob Silterra
Software Engineer
Broad Institute

[nkc]

Sorry, but i haven't checked this group in a couple of weeks. First, yes the memory low issue is gone in the snapshot version. That said, the snapshot version was doing some other weird stuff (like all genes on X chromosome were colored as if they had boatloads of polymorphisms), but I guess that's because the snapshot builds are works in progress. Will this get fixed in later versions? 

[Jim Robinson]

Hi, we're not seeing this, perhaps you had selected the wrong assembly
for your BAMs?

[Jim Robinson]

The amount of memory in the node is irrelevant,  how much memory was allocated to Java upon startup?  How exactly did you start IGV?

Hi Jim --

  I just saw the "memory is low, reading terminating" message on a node with 128 gigs of memory and IGV 2.3.0!  I will load the snapshot, but I expect the same problem..  any thoughts?

Cheers,

Roger

On Saturday, March 23, 2013 12:33:46 PM UTC-4, nkc wrote:

I recently upgraded to Mac OS 10.8.3 and downloaded the 2 GB version of IGV 2.2. After viewing several different genes, I invariably get the above message. If i follow my "activity monitor" I can observe that the memory used by IGV increases with each new gene I view (starts at ~400 GB) and, expectedly, when I have 4 tracks it increases faster than when I have fewer tracks. Once the memory gets to 2 GB the the above message appears. I'm not a computer savvy user, but it seems to me that I should be able to clear out that memory used by the previous genes viewed (I really don't care about the "back" button, if that's why these things accumulate). 

Any advice? 

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "igv-help" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/igv-help/Ci8d9GRubyw/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to igv-help+u...@googlegroups.com.

[orbits...@gmail.com]

yeah, i had forgotten to allocate more than the default 2 gigs -- you caught me before I deleted the message!  all good now that I allocate 120g on java startup.

I am having some trouble when I increase the scale at which bam coverage gets displayed above the default 30; reads get loaded into memory but coverage sometimes does not display..  should I convert my bams into a more efficient format?

[Jim Robinson]

Hi, depending on how you start the default can be as low as ~64 MB (e.g. double clicking the jar or not specifying memory at all).

That sounds like a bug,  perhaps coverage is not recomputed until forced to by for example going to another locus.  In any event for coverage it is much more efficient to pre-compute.   You can do this with igvtools, which outputs a "tdf" file for coverage.

Jim

[Kaustav Mukherjee]

Hi

I'm getting this error message also. I'm visualizing RNA-Seq data with high coverage on both strands. I have a 16GB Mac Pro with OS X 10.9 (Mavericks). I initially downloaded the Mac App for IGV 2.3.0 and got the error. Then I launched the Webstart with 10GB memory and also tried the Snapshot build suggested above - still have the error. It does not appear immediately though..takes a while. Also I've tried other things like unchecking "downsample reads" etc. to no avail. Kindly advice.

[Jim Robinson]

Hi,

Could you send me your "prefs.properties" file, and also your "igv.log"
file? Both are in the "igv" folder in your home directory. You can
send them to igv-team (at) broadinstitute.org.

Jim

[yl...@nyu.edu]

Hi,

I also get this error....I am running OS X El Capitan version 10.11.1. I tried to look at 12 tracks of bam files (the coverage profiles). I tried the java web start version (macOS with 2GB) as well as the Mac OS app. Both cases this error message happens after I have viewed 10-15 genes.... the memory use keeps building up and the error msg shows up after it reaches somewhere around 2GB. please advice.

Many thanks,

Ying

[Jim Robinson]

Hi Ying,

What version of IGV are you using?  The latest (check the version number from the help menu).

Jim

--

---

You received this message because you are subscribed to the Google Groups "igv-help" group.

To unsubscribe from this group and stop receiving emails from it, send an email to igv-help+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/igv-help/2ca1dfc8-d9de-46f8-8f21-297be2a1e2a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[yl...@nyu.edu]

Hi Jim,

The MacOS App is 2.3.32.

The java web start version is 2.3.66(95)

Thanks,

Ying

[Jim Robinson]

Try the latest version of IGV,  some memory leaks were fixed recently which might fix your problem.

To view this discussion on the web visit https://groups.google.com/d/msgid/igv-help/50145ce4-4f59-4826-a448-d016c5a39544%40googlegroups.com.

[yl...@nyu.edu]

Hi Jim,

I have tried the 2.3.66 version for MacOS app and java web start, but I still run into the low in memory issue after viewing about 10 genes....

Ying

[Jim Robinson]

Do you still have the "downsample reads" button unchecked?  You should definitely leave that checked, if you uncheck it and hit a gene with deep coverage you could eat up all available memory quickly.

Can I ask why you are looking simultaneously at 12 BAM files?   Are you just interested in coverage or also SNPs?

Jim

[yl...@nyu.edu]

Hi Jim,

I will try the "downsample" button.

I am interested in the coverage profile actually, specifically to validate some splicing variants by eye.

I have tried to convert to tdf files and to view that instead. It works really fast that way, but I don't like the choppy look of the coverage profile (I guess I could have tried smaller window size), so I got back to bam files....

Thanks,

Ying

[James Robinson]

I was going to suggest creating TDF files but you know about that option already, and also that you can reduce the window size to 1.   That will create large files, but still much smaller than BAM files.    I don't know what could be accumulating memory and will look into that again.  The only other immediate suggestion I have is to re-check downsample reads,  and in fact reduce "Max read count" for the sampling window to something small.   All the reads are used for the coverage calculation,  downsampling only affects how many reads are kept in memory for display.

To view this discussion on the web visit https://groups.google.com/d/msgid/igv-help/2d95b9e6-8e1c-4ae9-a24f-e5bbb91cd422%40googlegroups.com.

[yl...@nyu.edu]

Thank you very much for your help!

[James Robinson]

It just occurred to me,  perhaps a useful option for BAM files would be to display coverage only,  i.e. discard all reads after coverage is calculated.