DiVa software problems : The replies

A big THANK YOU to all the people who responded to my mail regarding
DiVa software problems; I certainly have a lot to try. Here are the
replies for anyone else who is interested. (My original message is
included at the end.)

Thanks again,
Helen
________________________________________
We used to run 4.0, and now run 6.1. With both versions, we have found
it necessary for reliable operation to empty the database after EVERY
experiment. (we send to a server) Even with that, about once a month we
have to reinstall the DIVA software. And every 4-6 months, we have to
deinstall and then reinstall JAVA. So, the answer is yes, the number of
experiments does matter...the more there are in the database, the slower
DIVA will run, and the more glitches you will get.
________________________________________
We have had similar problems to yourself , in fact with respect to the
Aria almost identical, the only solution to this was to ask BD to
replace the computer on out Aria which they were happy to do once I
documented the series of errors and lost sort time over 2 moths. in
terms of the LSR II we had some issues with lost list mode data , this
was resolved by upgrading to version 6 then version 6.1.1. We did go
through some very frustrating times with the Aria especially and learnt
from the experience. From day one defragmenting the hard drives on a
weekly basis also clearing out the database at the end of every month by
way of archiving current moths' data using the database manager , as
well as making a copy of each experiment on a DVD (DVD's) then deleting
all old experiments from the database , thereby ensuring that the
database on all our instruments was only ever at a maximum of one
month's data big has always helped us avoid slow recovery of files or
acquisition. Since we have had our new Aria computer and there is much
more traffic through our core facility we have now banned the use of
memory sticks and placed antivirus software onto all of our instruments
, this is upgraded as part of our weekly maintainance schedule and a
scan of all hard drives made , as well as on access scan being enabled .
We now are running very smoothly.
________________________________________
LSRII:
I also found that when we change voltages specifically FSC and SSC there
is a delay, but I found that it is dependent on how many experiment
files you have in that folder. I think the bottom line is that DIVA is
quite resource dependent and you therefore have to try reduce what you
can i.e. Delete experiments etc. I have definitely noticed that if I log
in as a user with virtually no experiments that it works much much
quicker
I have not find the solution yet to all of the above problems but have
learnt to be more watchful and cautious when acquiring, but the
'easiest' solution seems to be to try reduce the amount of experiments
you have, I have tried defragging but that didn't seem to help.
________________________________________
We are still running DiVa 4.0.something. My service engineer didn't like
5.0, and 6.0 is (of course) an upgrade we will have to pay for. It
doesn't seem to be a part of the service contract, for some strange
reason! (smile) There are several things I have found using the DiVa
software:
1. It is extremely memory and processor intensive. I only have the
things I require running in the background. I don't do anything else
that may be memory intensive or may require the processor to run more
than necessary for fear that it will slow down the software to the point
where it may become unusable.
2. The javascript implementation appears somewhat buggy. This means that
java will NOT release memory as it should, and therefore starts taking
up more and more available memory. When it gets much higher than 500,000
Kb it begins to slow down and eventually becomes unusable. Yes, I have
undergone the freeze-ups you describe, and when I discussed this with my
service engineer, he suggested I monitor it using Task
 Manager. When it
appears to get too high, turn off the streait back up again, and the memory that was
previously taken is now freed
and the system should run better.
3. Contrary to what you may (or not) have heard, when the database gets
too large it will slow down the program. It seems that everyone has a
differing opinion as to what constitutes "too large." I keep my database
as lean as possible. Export the experiments and archive off the things
you don't need from the hard drive. Keep your data drive (the D drive in
most cases) as clean as possible, and use less than 50% of the drive
itself. The C drive also benefits from this regimen. The program will be
happier.
4. Defragment BOTH the C drive and the D drive on a regular basis. How
often depends on how much you use the machine. I will do it every month
(as well as archive data) during the monthly cleaning we do on the
systems; we have both an LSRII and an Aria. The files get huge and will
eat the disk space in a hurry.
5. I have not seen the empty plot problem you describe. I do know that
if there are very many gates or too much Boolean logic the machine has
to calculate and display or too much data, it can cause the system to
behave in unusual ways. I have seen it take about 5 minutes for the data
to display or to even quit "acquiring". This is quite frustrating. Also,
I have seen times when DiVa no longer responded, and I had to use Task
Manager to force the program to quit, I sometimes (a) no longer can
access the data; or (b) the gating strategy completely lost, as well as
the worksheet; or (c) the plots and gates are missing from the
worksheet, but the strategy is still there. Redrawing the gates on the
appropriate plots reveals it. Weird but true.
________________________________________
I do not have LSR and no answer for the first one. However, I did see
the same problems on Aria quite a few times during the past more than 2
year's FACSAria operation. If force quite - restart Diva did not work, I
have to shut down computer and machine, then restart everything. Indeed,
it takes time, samples risk and client complaint, very stressful. If you
could get more responds like we met, I guess that is the Diva limitation
which we should ask BD for help.
________________________________________
The second problem you reported with the LSR II has happened to me on
Diva 4.1.2, and yes it is about the number of experiments. I lost a very
important analysis experiment on my Aria, during the analysis everything
looked fine, I could print etc, but a few days later when I reopened the
experiment to export it (my Aria is off the network) all the data was
gone. BD advised me that this was because I had too much data stored in
the software. They recommend that the browser window should be never
more than 1/3 full (with experiments or tubes!). What happens is that
before the data is saved it is stored in a temporary file, if there is
insufficient space in the software it continues to fill the temorary
file, and when you quit Diva the temporary file is deleted, no warning,
no
error message. I sometimes find on the Aria, after a blockage, or and
emergency stop that my dot plots are free from data, the data is
returned by opening the instrument settings and changing the voltage
settings by a volt then returning them to their original setting. I have
a HTS on the LSR II, and with Diva 4.1.2, I can only analyse two 96 well
plates at a time, then I have to export the data, delete the plates and
move on. If you try and analyse a third plate the software freezes or
freezes then crashes. It appears that the golden rule is to keep as few
experiments in Diva as possible (if they are rarely used export them and
import when needed), and export all the data ASAP.
________________________________________
If you only notice it for particular users then the simplest way to fix
it may be to recreate the users login. We find that some user accounts
get corrupted ( not sure why). The problem also happens with particular
experiments when 
they are duplicated to many times.
_______________________We have had the software not respond to aquisition commands and
have
attribitued it to having both the LSRII ethernet and our site network
ethernet connected while trying to aquire data. Is that a possibility in
your case? Just disconnecting the site ethernet cable corrected the
problem.
________________________________________
Having all data stored in a database, like DiVa does, imposes some
severe limitations on the total amount of data one can store. I believe
the limit for the one supplied with DiVa is 5GB (I could be wrong here,
but the exact number's pretty meaningless anyway). It's therefore
important to export your experiments and remove them from the DB as soon
as possible, especially the ones containing large datasets.
The other data limitation we've come across ourselves is a problem with
the error log size. DiVa stores all internal error messages etc. in a
plain text log file, as do many other apps. Problem here is that it
generates LOTS of messages and keeps appending to the same file without
ever checking or reducing the size (i.e. by removing the oldest ones).
Windows can only handle file sizes up to a Gig or so, and things start
behaving oddly when you keep appending to files that large - including
DiVa itself, even though there's nothing really wrong with that
application itself.
I'd therefore recommend you check the size of the error log, and remove
it or rename it to something other. There's no risk involved; DiVa will
just generate a minty fresh new error log if the old one is missing (or
renamed). 
________________________________________
I have similar problems on my FACS ARIA with Diva5. It mainly happens
when I have to save 1000000 events or more, also my database is not even
half full. Especially when I have already a "sample" in the "Experiment"
with 10000000 events saved. I have no problem with 50000 events saved. I
delete those "big" experiments as soon as possible. If I have to do more
sorts at the same day, where I am forced to save that many events, it
helps to do each sample in a new created "experiment".
________________________________________
1. open my computer-new volumn(D)-BD Database-open property to see how
much data memory: BD Database memory must be below 15G!!! otherwisw Diva
sofeware will behave very strange way like you have found.
2. If BDDatabase memory is above 15G, Please export and delete the
experiment files from Diva sofware to new volumn D (BD Export).
3. weekly Defragmention on new volumn(D)hard drive.
________________________________________
I would recommend that you export all experiemnts and data from drive C:
to D: and then de-fragment drive C: and see if these problems improve.
Diva does seem to get bogged down when there is too much data.
________________________________________
With version 6 I think the limit is having 12 GB in the BDDatabase. WIth
version 4 on our Vantage the software hangs up at 2GB. I don't think the
number of experiments is the deciding factor, so check your database
size. Also it is not 12GB per user, but total... I have seen plots that
did not display after collecting, unless I went to a different tube and
then back. This has only happened when I altered the compensation after
doing autocomp and after recording a few files. Sounds like you are
having some kind of database problem.
________________________________________
We have experienced this lock-up on our Aria, (DIVA 5.2) but with only
one user. The recommendation was to delete and rebuild the affected
user. For other reasons we haven't done that yet so I can't report
outcome.
________________________________________
ORIGINAL MESSAGE:
We have been experiencing major problems with the DiVa software we use
on our LSRII. We also have some problems with our Aria that we would
like to know if anyone else has experienced, as we are not sure if they
are related to the software or not. We initially saw the problems using
DiVa v5.0 and hoped that the new DiVa v6.1.1. w
ould fix the problems,
but it hasn’t.

LSRII
1. During acquisition some or all of the dot plots are empty. When the
sampdata is displayed as normal. Obviously this is far from ideal since you
need to be able to see if your sample during acquisition in case there
are any problems.
2. Some people have also run a set of samples and then gone back to find
that the saved files are no longer there.
3. Since DiVa v6.1.1 was installed, they have also seen that the machine
does not stop acquiring when it should.

ARIA
The software fails to respond when we click on unload, acquire, sort
etc. The only way out of this, is to force quit and restart the
software. We have wasted huge amounts of time during sorts messing about
with this, as you have to wait for the stream to stabilize etc. We have
also lost some samples because even though you have clicked to stop
acquiring, it doesn’t always actually stop.

Has anyone experienced any of the same problems and if so, how did you
fix it? Is it possible that it is related to the number of experiments
in the DiVa software, I know there is a limit to how much data you can
acquire into a single ‘Experiment’, but does the number of separate
experiments affect the performance of the software?

Any help/input will be hugely appreciated.
________________________________________



Helen Ferry, D.Phil
FACS Manager
Haemopoietic Stem Cell Laboratory
Weatherall Institute for Molecular Medicine
John Radcliffe Hospital
University of Oxford
Headington
Oxford 
OX3 9DS 
United Kingdom 

+44 1865 222340