RE: FACS Diva software

From: Bushnell, Timothy <Timothy_Bushnell@URMC.Rochester.edu>
Date: Fri Aug 12 2005 - 07:52:28 EST
I have usually only had the minimal number of plots on a worksheet that I
needed to ensure that the samples I was running looked reasonable. 


Being a Friday morning, and having some time on my hands, I decided to check
out Ryan's comment about speeding up the display process by
reducing/removing plots.


13 parameters	2e6 events collected	   5 dot plot		4 gates
500 events displayed	  refresh time 63 sec


13 parameters	2e6 events collected	   1 dot plot		0 gates
500 events displayed	  refresh time 53 sec	     

13 parameters	2e6 events collected	   1 histogram	     0 gates
500 events displayed	  refresh time 52 sec


13 parameters	2e6 events collected	   3 dot plots	       2 gates
500 events displayed	  refresh time 59 sec

13 parameters	2e6 events collected	   3 dot plots	       2 gates
5000 events displayed	 refresh time 62 sec

13 parameters	2e6 events collected	   3 dot plots	       2 gates
50000 events displayed	 refresh time 64 sec


So, as Ryan suggests, decreasing the number of plots increases refresh time,
but the type of plot does not seem to matter as much. Increasing the number
of displayed events increases the 


I also wonder if the refresh can be affected by the 'worksheet' vs 'global
worksheet'.  


Yours with a grain of salt on a Friday morning.


Timothy Bushnell, Ph.D.

Director, CPBR Flow Lab

University of Rochester

tel: 585-273-1361

http://www.urmc.rochester.edu/Aab/geneped/flow/
<http://www.urmc.rochester.edu/Aab/geneped/flow/> 

http://www.urmc.rochester.edu/wnyfug/
<http://www.urmc.rochester.edu/wnyfug/> 


Use of the return email address on this message for commercial purposes is
prohibited. The transmission of unsolicited commercial material is
prohibited under federal laws (47 USC 227). Civil penalties and claims of
$500.00 per occurrence (47 USC 227[c]) may be assessed for violations.

  _____  

From: Ryan Duggan [mailto:rduggan@flowcity.bsd.uchicago.edu] 
Sent: Thursday, August 11, 2005 9:40 AM
To: cyto-inbox
Subject: Re: FACS Diva software


Stuart,


I'm not a technical computer person, but I have been able to speed up this
process by moving all or most of the plots off-screen, or by only creating
one plot or histogram (a single histogram may be best).  It doesn't help
much to see your data as it's being collected, but as long as you have set
up the instrument properly, you technically wouldn't need to see your data
until it gets analyzed.  I've always attributed this to the graphics card,
and I believe that even the BD specified graphics card is not robust enough
to display all that data.  For those who work with high-end graphics on
their computers, they have commented that the graphics card on our computer
is really slow.  I don't know, however, if you could simply upgrade to a
higher-end graphics card; you'd probably have to check that with BD.  It may
also have something to do with the Java platform it runs on, which I've
heard many programmers dislike, and in that case, we're pretty much stuck.


Ryan Duggan

Flow Cytometry Facility

University of Chicago



On Aug 9, 2005, at 11:50 PM, Stuart Berzins wrote:





Has anyone got a way to improve the speed of the FACS Diva software? We are
using a 6-color BD LSR2 with the latest FACS Diva software. The software
itself does all that we want it to do, but it struggles to cope with large
data files (especially files above 2 million). We find that when acquisition
stops, there is a delay of up to 3 minutes for various forms of data
processing before another acquisition can take place. During the stoppage,
progress bars appear to say that the data is being prepared for display etc.
Is there anyway to cut back on this time? Worse still, when acquisition
gating, this delay is proportional to the total number of cells looked at,
rather than the cells to be stored. Lastly, when a sample involves numbers
above 5 million, there needs to be a continual appending of data or the
software will simply shut down and say that memory is insufficient at around
the 4 million cell mark.


We have upgraded the computer to the highest performance available, adjusted
the graphics card to BD specifications, reduced the 'events shown' to a
minimum, avoided statistical displays and so forth, all with no discernable
benefit. Because the software won't let us cut this process short and just
jump to the next tube, some experiments have up to 2 hours spent just
sitting there waiting for the machine to let us acquire new data. We were
told that the latest version of the software would be much quicker, but
after installing that a month ago, there seems to be no change (same story
with the version before that too). I am told this is a widespread issue, but
has anyone found a way to improve things?


Stuart

-- 

Stuart Berzins Ph.D,

Research Fellow, Godfrey Laboratory,

Department of Microbiology and Immunology,

The University of Melbourne,

Parkville 3010,

AUSTRALIA.

email: berzins@unimelb.edu.au <mailto:berzins@unimelb.edu.au> 

Ph:    +61-3-8344-5704

Fax:   +61-3-9347-1540

Mobile: 0427 849 123
Received on Fri Aug 12 16:38:00 2005

This archive was generated by hypermail 2.1.8 : Sat Jan 14 2006 - 22:03:52 EST