Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralCardiologyVisionDentistryPharmacyLaboratoryNutritionAlternative
Diseases and Disorders
AIDSAlzheimer'sArthritisAsthmaCancerBreast CancerDiabetesEpilepsyGlaucomaHepatitisHerpesLupusProstate BPHProstate CancerProstatitisSinusitisTinnitus

Medical Forum / Diseases and Disorders / AIDS / January 2008

Tip: Looking for answers? Try searching our database.

PURDUE CYTOMETRY DNA DELETE AFTER YOU READ PURDUE CYTOMETRY MAIL LIST

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mitch Haynes - 17 Jan 2008 19:52 GMT
Verity House software
RE: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Maybe in
reply to ]
From: VSH Tech Support <Tech@vsh.com>
Date: Fri Feb 16 2007 - 09:01:56 EST
Stevan

At the risk of sounding like a commercial, WinList can do exactly what
you
want.  The problem of "sucking up air" or perhaps having a clogged
nozzle at
the end of a run has gotten all of us at one time or another, and then
the
data (most of which is probably fine) appears to be unusable.  WinList
addresses this issue with the FTIM parameter, which is basically a
"chronology" parameter defined over 1024 channels.  Each event is
assigned
an FTIM channel based on its order in the listmode file, channel zero
having
the first n/1024 events, and channel 1023 having the last n/1024
events.

Displaying a 2P dot plot of FTIM vs. side scatter, for example, will
clearly
show the aberrant events.  You may then gate on the "good" events, or
gate
out the "bad" events.  Either way, you can salvage an otherwise bad
run.

You can also save the gated listmode using WinList's Save Data Source
option, and it will contain only
the "good" events.  Another feature of the Save Data Source option is
the
ability to set the number of events to save in the listmode file,
which at
least partially addresses the desire to save a larger file into
smaller
segments that will each have the same number of events within given
regions,
as you are requesting.

Best regards,
Don
Donald J. Herbert
Technical Support Manager
Verity Software House

-----Original Message-----
From: Stevan Lauriault [mailto:stevan@lauriault.com]
Sent: Friday, February 09, 2007 6:24 PM
To: cyto-inbox
Subject: Re: gate-specific data cropping

Thanks for your very helpful comments.    I guess what I am trying to get
at
is this: is
there any analysis software available that can reduce list mode data
in a
reverse order-specific matter (in reverse sequence)?  Correct me if
I'm
wrong, but I believe this function would also help in the event that a
user
lets a sample run dry and sucks up air bubbles, or over collects their
intended gating target (for example, in acquisition and storage, 5000
of
R1).

Thanks,

Stevan
---------- Original Message ----------------------------------
From: "Byron Ellis" <bcellis@stanford.edu>
Date:  Wed, 7 Feb 2007 16:21:28 -0800

>On 2/7/07, Stevan Lauriault <stevan@lauriault.com> wrote:
>> Hi and thanks,
>>
>> Since we want to directly compare MFIs (in FL2) between any two
>> subsets (R1 vs. R3)
>that are isolated on a bivariate dot plot (FL1 vs. FL4), doing so in
>separate sample tubes would introduce the extra probability of
>experimental
error between sample tubes.
>Directly comparing the subsets from the same sample tube, and even
>better, the same data set, would eliminate this extra unknown.
>
>It doesn't necessarily eliminate the unknown, it may just keep you from
>finding out about it. If you were to prepare one sample on Monday, see
>significant differences, celebrate, etc and then on Wednesday prepare
>another sample where you didn't you'd probably want to know that (and
>figure out why). Simply taking the FACS tube off the cytometer and
>putting it back on won't give you that information. Now, would I be
>surprised if that actually happened in your case? Yes.
>Would I do replicates anyway? Yes.
>
>> Let us say we have acquired 100,000 total events (stained with 3
>> fluorochromes,
>measured in FL1, FL2, and FL4 respectively).  We are using a bivariate
>dot plot of FL1 vs. FL4 in which we are isolating 3 subsets (R1, R2,
>and R3) based on their relative expressions of FL1 vs. FL4.  We then
>want to compare the MFIs, as measured in FL2, among these subsets.
>Within those 100,000 total events, there are 500 of R1, 700 of R2 and
>1200
of R3.

>> If we crop the 100,000 total events to 75,000 total events (from the
>> top in
>stack-collected data), there will become exactly 500 events in the R2
region. If we
crop
>the 100,000 total events to 40,000 total events, there will become 500
events in R3.

>> Now the three populations; R1, R2, and R3 each have exactly 500 total
>> events, and we
>can directly compare MFIs among the subsets that have identical sample
sizes.    We could
>also then say that, when comparing means between these subsets under
>identical experimental conditions, Rx gives a consistently higher
fluorescent signal than Ry.

>Well, depending on what you're doing (you've never said how you intend
>to compare means), equal sample sizes is not particularly required so
>there's no particular reason to cut the data to obtain equal sample
>sizes. For example, one-way ANOVA (or one-way ANOVA with repeated
>measure in the event that you chose to do _real_ replicates), which
>simply says "they're different" (there are other tests, variants of
>one-sided t-tests essentially, that give you directionality statements
>such as mu_{R_1} > mu_{R_2} ). In this case your assumptions are:
>
>1. Each group is independent
>2. Normality of group populations (or at least "close enough" to
>Normal) 3. The _population_ variances of the dependent variable for
>each group are equal (or pretty close). (Actually check this. It would
>be unsurprising to encounter large differences in the population
>variances among your different groups).
>
>Like I say, it depends a bit on what you intend to do for your
>analysis. For example, _two_-way ANOVA actually expects equal sample
>sizes.
>
>> Is this a reasonable strategy?  Is there any software available that
>> can perform this
>function?
>
>On an FCS file directly? Probably not (neither the manipulation of the
>flow data nor the testing). Once you've got the data out of FCS form
>and appropriately labeled with group membership or split into separate
>files or something similar, then any reasonable statistics package
>(Excel is not included in the list of reasonable statistics packages)
>can perform the statistical tests.
>
>Personally, I use R (http://www.r-project.org) for analyzing all the
>flow data I have, but it can be intimidating for new users (though
>extremely powerful once you learn to use it). There are two packages in
>R for manipulating flow data at the moment (prada and rflowcyt),
>available through the Bioconductor Project
>(http://www.bioconductor.org) that can actually read in and manipulate
>FCS data directly or slightly manipulated data from say FlowJo (so you
>can do your gating there for example). I'm also part of a group made up
>of the people who did rflowcyt and prada that are making a combined
>package of the best bits of both (and some other new bits) that we
>expect to be available in the next Bioconductor release (probably
>sometime in April).
>
>Hope that helps,
>
>Byron
>
>> Kind Regards,
>>
>> Stevan Lauriault
>>
>> ---------- Original Message ----------------------------------
>> From: "Byron Ellis" <bcellis@stanford.edu>
>> Date:  Tue, 6 Feb 2007 12:17:35 -0800
>>
>> >Speaking as a statistician, I would not count running the same tube
>> >3 times or simply cutting the FCS file (the two are equivalent) as
>> >three replicates so I wouldn't do either to achieve what you want
>> >(though I can imagine situations where you would resample to
>> >calculate statistics). To get three replicates you would have to
>> >prepare three separate samples---you're interested in the
>> >variability of the mean due to experimental error as well as the
>> >biological variability of the cells and a single sample preparation
>> >only
captures the latter.

>> >On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
>> >> Dear All,
>> >>
>> >> Question:
>> >>
>> >> We are isolating leukocyte subsets to measure and compare relative
>> >> levels of
>expression
>> >> of certain antigens.  For example, there are three subsets within
>> >> a bivariate dot
>plot;
>> >> gated on R1, R2 and R3 respectively, and we would like to
>> >> statistically analyze the relative mean fluorescence intensities
>> >> of a
biomarker, among the subsets.

>> >> To get statistically comparable sample sizes among these subsets,
>> >> we are running
the
>same
>> >> tube three times and changing the storage criteria to 500 events
>> >> for each subset (example, the first run is 500 events of R1, the
>> >> second 500 of R2, and the third is
>500
>> >> of R3).  Instead of repeating the same tube three times, and
>> >> wasting valuable
>sample, it
>> >> seems like a good idea to "crop" a preexisting data file of, for
>> >> example, 100,000
>total
>> >> events, three times to get an identical sample size for all three
>> >> gated subsets
(R1,
>R2,
>> >> and R3).
>> >>
>> >> Scientifically, this shouldn't be a problem, since flow cytometry
>> >> data is collected randomly within the same sample tube.  Not only
>> >> could we run one acquisition to get different monocyte subset
>> >> populations, but also to statistically compare constant
>numbers
>> >> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc. However,
>> >> I can see why
>some
>> >> scientists might be uneasy with the idea of manipulating raw
>> >> list-mode
data.

>> >> However, Since the data is collected randomly from the same
>> >> sample, doing this
>should
>> >> give exactly the same readings as if we just collected less
>> >> events, since we would
>only
>> >> be cropping (from stack-collected data) the most recent events
collected.

>> >> Currently, we are acquiring 3 different data files for each tube,
>> >> and adjusting the acquisition and storage settings for each
>> >> acquisition.  Is there a way to perform a gate-specific data
>> >> cropping function with any current flow cytometry data analysis
software?

>> >> Kind Regards,
>> >>
>> >> Stevan Lauriault
>> >>
>> >> ________________________________________________________________
>> >> Sent via the WebMail system at lauriault.com
>> >
>> >--
>> >Byron Ellis (byron.ellis@gmail.com)
>> >"Oook" -- The Librarian
>>
>> ________________________________________________________________
>> Sent via the WebMail system at lauriault.com
>
>--
>Byron Ellis (byron.ellis@gmail.com)
>"Oook" -- The Librarian

________________________________________________________________
Sent via the WebMail system at lauriault.com
Received on Fri Feb 16 16:38:00 2007
*    This message: [ Message body ]
*    Next message: Mara.Rocchi@moredun.ac.uk: "ovine T regs"
*    Previous message: Atwater, Susan: "RE: Reporting clinical results"
*    Maybe in reply to: Stevan Lauriault: "gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 E
RE: DNA analysis software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ]
From: VSH Tech Support <Tech@vsh.com>
Date: Wed Feb 21 2007 - 11:29:45 EST
Hello Ibtissam,

ModFit LT, for PC or Mac, has advanced modeling capability for
research
applications in DNA cell cycle analysis.  You may use any of the model
templates the program offers, or create your own models for non-
traditional
analysis, including non-mammalian DNA cell cycle studies. ModFit LT
can be
linked to our WinList program to provide a complete cell cycle
analysis on
any number of sub-populations with a single click of a button.

For an overview, visit  <http://www.vsh.com/products>
http://www.vsh.com/products .

Best regards,

Don

Donald J. Herbert
Technical Support Manager
Verity Software House

________________________________

From: Ibtissam Abdul-Jabbar [mailto:iajabbar@cicr.uq.edu.au]
Sent: Wednesday, February 14, 2007 11:41 PM
To: cyto-inbox
Subject: DNA analysis software

Dear All, before buying software to analyse DNA on PC, I would like to
get
your opinion. I already have ModFit for Macintosh.

What are you using and what do you recommend for research purposes.

Is MultiCycle Av the one of choice?

I appreciate your comments.

Ibtissam A Jabbar (PhD)

Manager of the FACS facilities

Diamantina Institute for Cancer, Immunology and Metabolic Medicine
(DI)

The University of Queensland

Level 4 R Wing

Princess Alexandra Hospital

Ipswich Rd Buranda QLD 4102

Australia

Ph: 07 3240 5945

Fax: 07 3240 5946

Mob: 0401154744
Received on Thu Feb 22 15:18:00 2007
*    This message: [ Message body ]
*    Next message: Uriel TK: "Re: Ratio Measurement of Mitochondrial
Membrane Potential with FACSDiva"
*    Previous message: Howard Shapiro: "Re: Ratio Measurement of
Mitochondrial Membrane Potential with FACSDiva"
*    In reply to: Ibtissam Abdul-Jabbar: "DNA analysis software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: WEHICytometry <facs_copy@wehi.EDU.AU>
Date: Mon Feb 12 2007 - 18:25:38 EST
Stevan,

For what it's worth, we have a utility we call Hackit that can crop
cells from the front or back of a FCS file ( see http://
www.wehi.edu.au/cytometry/freesoftware/index.html).  We use it for
the tasks you suggest in cleaning up violated data.  I don't know
how
useful that would be for your current purpose because it can't do
gating; numbers clipped are total cell numbers.  I guess if you knew
the proportions of your gated cells you could eventually clip out
the
file segments you need.

Frank Battye.

On 10/02/2007, at 10:24 AM, Stevan Lauriault wrote:

> Thanks for your very helpful comments.    I guess what I am trying to
> get at is this: is
> there any analysis software available that can reduce list mode
> data in a reverse
> order-specific matter (in reverse sequence)?    Correct me if I'm
> wrong, but I believe this
> function would also help in the event that a user lets a sample run
> dry and sucks up air
> bubbles, or over collects their intended gating target (for
> example, in acquisition and
> storage, 5000 of R1).

    |     |  << The Cytometry Laboratory
     \__/ <<<< The Walter & Eliza Hall Institute
------!!<<<<<< 1G Royal Parade, Parkville
     /!!\ <<<< Victoria 3050, Australia
    o !! \  << ph: 61_3_9345 2540, fax: 61_3_9347 0852
Received on Tue Feb 13 15:18:00 2007
*    This message: [ Message body ]
*    Next message: Uriel TK: "Re: early apoptotic cells"
*    Previous message: Darzynkiewicz, Zbigniew: "RE: early apoptotic
cells"
*    In reply to: Stevan Lauriault: "Re: gate-specific data cropping"
*    Next in thread: VSH Tech Support: "RE: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Maybe in
reply to ] [ Next in thread ] [ Replies ]
From: Stevan Lauriault <stevan@lauriault.com>
Date: Fri Feb 09 2007 - 18:24:07 EST
Thanks for your very helpful comments.    I guess what I am trying to get
at is this: is
there any analysis software available that can reduce list mode data
in a reverse
order-specific matter (in reverse sequence)?  Correct me if I'm wrong,
but I believe this
function would also help in the event that a user lets a sample run
dry and sucks up air
bubbles, or over collects their intended gating target (for example,
in acquisition and
storage, 5000 of R1).

Thanks,

Stevan
---------- Original Message ----------------------------------
From: "Byron Ellis" <bcellis@stanford.edu>
Date:  Wed, 7 Feb 2007 16:21:28 -0800

>On 2/7/07, Stevan Lauriault <stevan@lauriault.com> wrote:
>> Hi and thanks,
>>
>> Since we want to directly compare MFIs (in FL2) between any two subsets (R1 vs. R3)
>that are isolated on a bivariate dot plot (FL1 vs. FL4), doing so in separate sample
>tubes would introduce the extra probability of experimental error between sample tubes.
>Directly comparing the subsets from the same sample tube, and even better, the same data
>set, would eliminate this extra unknown.
>
>It doesn't necessarily eliminate the unknown, it may just keep you
>from finding out about it. If you were to prepare one sample on
>Monday, see significant differences, celebrate, etc and then on
>Wednesday prepare another sample where you didn't you'd probably want
>to know that (and figure out why). Simply taking the FACS tube off the
>cytometer and putting it back on won't give you that information. Now,
>would I be surprised if that actually happened in your case? Yes.
>Would I do replicates anyway? Yes.
>
>> Let us say we have acquired 100,000 total events (stained with 3 fluorochromes,
>measured in FL1, FL2, and FL4 respectively).  We are using a bivariate dot plot of FL1
>vs. FL4 in which we are isolating 3 subsets (R1, R2, and R3) based on their relative
>expressions of FL1 vs. FL4.  We then want to compare the MFIs, as measured in FL2, among
>these subsets.  Within those 100,000 total events, there are 500 of R1, 700 of R2 and
>1200 of R3.
>>
>> If we crop the 100,000 total events to 75,000 total events (from the top in
>stack-collected data), there will become exactly 500 events in the R2 region.    If we
crop
>the 100,000 total events to 40,000 total events, there will become 500 events in R3.
>>
>> Now the three populations; R1, R2, and R3 each have exactly 500 total events, and we
>can directly compare MFIs among the subsets that have identical sample sizes.    We could
>also then say that, when comparing means between these subsets under identical
>experimental conditions, Rx gives a consistently higher fluorescent signal than Ry.
>
>Well, depending on what you're doing (you've never said how you intend
>to compare means), equal sample sizes is not particularly required so
>there's no particular reason to cut the data to obtain equal sample
>sizes. For example, one-way ANOVA (or one-way ANOVA with repeated
>measure in the event that you chose to do _real_ replicates), which
>simply says "they're different" (there are other tests, variants of
>one-sided t-tests essentially, that give you directionality statements
>such as mu_{R_1} > mu_{R_2} ). In this case your assumptions are:
>
>1. Each group is independent
>2. Normality of group populations (or at least "close enough" to Normal)
>3. The _population_ variances of the dependent variable for each group
>are equal (or pretty close). (Actually check this. It would be
>unsurprising to encounter large differences in the population
>variances among your different groups).
>
>Like I say, it depends a bit on what you intend to do for your
>analysis. For example, _two_-way ANOVA actually expects equal sample
>sizes.
>
>> Is this a reasonable strategy?  Is there any software available that can perform this
>function?
>
>On an FCS file directly? Probably not (neither the manipulation of the
>flow data nor the testing). Once you've got the data out of FCS form
>and appropriately labeled with group membership or split into separate
>files or something similar, then any reasonable statistics package
>(Excel is not included in the list of reasonable statistics packages)
>can perform the statistical tests.
>
>Personally, I use R (http://www.r-project.org) for analyzing all the
>flow data I have, but it can be intimidating for new users (though
>extremely powerful once you learn to use it). There are two packages
>in R for manipulating flow data at the moment (prada and rflowcyt),
>available through the Bioconductor Project
>(http://www.bioconductor.org) that can actually read in and manipulate
>FCS data directly or slightly manipulated data from say FlowJo (so you
>can do your gating there for example). I'm also part of a group made
>up of the people who did rflowcyt and prada that are making a combined
>package of the best bits of both (and some other new bits) that we
>expect to be available in the next Bioconductor release (probably
>sometime in April).
>
>Hope that helps,
>
>Byron
>
>> Kind Regards,
>>
>> Stevan Lauriault
>>
>> ---------- Original Message ----------------------------------
>> From: "Byron Ellis" <bcellis@stanford.edu>
>> Date:  Tue, 6 Feb 2007 12:17:35 -0800
>>
>> >Speaking as a statistician, I would not count running the same tube 3
>> >times or simply cutting the FCS file (the two are equivalent) as three
>> >replicates so I wouldn't do either to achieve what you want (though I
>> >can imagine situations where you would resample to calculate
>> >statistics). To get three replicates you would have to prepare three
>> >separate samples---you're interested in the variability of the mean
>> >due to experimental error as well as the biological variability of the
>> >cells and a single sample preparation only captures the latter.
>> >
>> >On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
>> >> Dear All,
>> >>
>> >> Question:
>> >>
>> >> We are isolating leukocyte subsets to measure and compare relative levels of
>expression
>> >> of certain antigens.  For example, there are three subsets within a bivariate dot
>plot;
>> >> gated on R1, R2 and R3 respectively, and we would like to statistically analyze the
>> >> relative mean fluorescence intensities of a biomarker, among the subsets.
>> >>
>> >> To get statistically comparable sample sizes among these subsets, we are running
the
>same
>> >> tube three times and changing the storage criteria to 500 events for each subset
>> >> (example, the first run is 500 events of R1, the second 500 of R2, and the third is
>500
>> >> of R3).  Instead of repeating the same tube three times, and wasting valuable
>sample, it
>> >> seems like a good idea to "crop" a preexisting data file of, for example, 100,000
>total
>> >> events, three times to get an identical sample size for all three gated subsets
(R1,
>R2,
>> >> and R3).
>> >>
>> >> Scientifically, this shouldn't be a problem, since flow cytometry data is collected
>> >> randomly within the same sample tube.  Not only could we run one acquisition to get
>> >> different monocyte subset populations, but also to statistically compare constant
>numbers
>> >> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc. However, I can see why
>some
>> >> scientists might be uneasy with the idea of manipulating raw list-mode data.
>> >>
>> >> However, Since the data is collected randomly from the same sample, doing this
>should
>> >> give exactly the same readings as if we just collected less events, since we would
>only
>> >> be cropping (from stack-collected data) the most recent events collected.
>> >>
>> >> Currently, we are acquiring 3 different data files for each tube, and adjusting the
>> >> acquisition and storage settings for each acquisition.  Is there a way to perform a
>> >> gate-specific data cropping function with any current flow cytometry data analysis
>> >> software?
>> >>
>> >> Kind Regards,
>> >>
>> >> Stevan Lauriault
>> >>
>> >> ________________________________________________________________
>> >> Sent via the WebMail system at lauriault.com
>> >
>> >--
>> >Byron Ellis (byron.ellis@gmail.com)
>> >"Oook" -- The Librarian
>>
>> ________________________________________________________________
>> Sent via the WebMail system at lauriault.com
>
>--
>Byron Ellis (byron.ellis@gmail.com)
>"Oook" -- The Librarian

________________________________________________________________
Sent via the WebMail system at lauriault.com
Received on Mon Feb 12 12:18:00 2007
*    This message: [ Message body ]
*    Next message: Dan Smith: "Interferon alpha & Interferon Beta
intracellular staining"
*    Previous message: RAJA ALAMELU: "[ seeking K562 cell line ]"
*    Maybe in reply to: Stevan Lauriault: "gate-specific data cropping"
*    Next in thread: WEHICytometry: "Re: gate-specific data cropping"
*    Reply: WEHICytometry: "Re: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

RE: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Maybe in
reply to ] [ Next in thread ]
From: Nebe-Von-Caron, G <g.nebe-von-caron@unipath.com>
Date: Thu Feb 08 2007 - 09:36:37 EST
The number of events collected will not be the influential thing as
with
a minimum of 500 events you get already a damn good estimate of your
MFI. Just as an educational exercise you should do is to look at MFI
estimate of one population over events. It should indicate that your
estimate if the sample mean after 100 "samples" (each cell being a
sample on its own) is already pretty good. You might want to look at
the
distribution of mean fluorescence or more important of single event
residuals (distance from mean) over time to see if they show a trend
which would indicate an unstable measurement.

In the sample you propose you are more likely to see differences based
on compensation variation between your 3 populations which again is
independent of the number of events looked at if more than 500 have
been
measured. It would indeed be interesting to see how much variation you
get in mfi between independent tubes as you are more likely to
increase
variation by the sample processing than by the measurement.

One control for your experiment would be to test the MFI distribution
by
swapping fluorochromes to demonstrate that you are independent of
compensation and to show that the change in MFI is not dependent of
steric hindrance or FRET, depending of the experimental / instrument
details.

Regards

Gerhard

> -----Original Message-----
> From: Stevan Lauriault [mailto:stevan@lauriault.com]
> Sent: 07 February 2007 15:16
> To: Cytometry Mailing List
> Subject: Re: gate-specific data cropping
>
> Hi and thanks,
>
> Since we want to directly compare MFIs (in FL2) between any
> two subsets (R1 vs. R3) that are isolated on a bivariate dot
> plot (FL1 vs. FL4), doing so in separate sample tubes would
> introduce the extra probability of experimental error between
> sample tubes.
> Directly comparing the subsets from the same sample tube, and
> even better, the same data set, would eliminate this extra unknown.
>
> Let us say we have acquired 100,000 total events (stained
> with 3 fluorochromes, measured in FL1, FL2, and FL4
> respectively).  We are using a bivariate dot plot of FL1 vs.
> FL4 in which we are isolating 3 subsets (R1, R2, and R3)
> based on their relative expressions of FL1 vs. FL4.  We then
> want to compare the MFIs, as measured in FL2, among these subsets.
>  Within those 100,000 total events, there are 500 of R1, 700
> of R2 and 1200 of R3.
>
> If we crop the 100,000 total events to 75,000 total events
> (from the top in stack-collected data), there will become
> exactly 500 events in the R2 region.    If we crop the 100,000
> total events to 40,000 total events, there will become 500
> events in R3.
>
> Now the three populations; R1, R2, and R3 each have exactly
> 500 total events, and we can directly compare MFIs among the
> subsets that have identical sample sizes.  We could also then
> say that, when comparing means between these subsets under
> identical experimental conditions, Rx gives a consistently
> higher fluorescent signal than Ry.
>
> Is this a reasonable strategy?    Is there any software
> available that can perform this
> function?
>
> Kind Regards,
>
> Stevan Lauriault
>
> ---------- Original Message ----------------------------------
> From: "Byron Ellis" <bcellis@stanford.edu>
> Date:  Tue, 6 Feb 2007 12:17:35 -0800
>
> >Speaking as a statistician, I would not count running the
> same tube 3
> >times or simply cutting the FCS file (the two are
> equivalent) as three
> >replicates so I wouldn't do either to achieve what you want
> (though I
> >can imagine situations where you would resample to calculate
> >statistics). To get three replicates you would have to prepare three
> >separate samples---you're interested in the variability of
> the mean due
> >to experimental error as well as the biological variability of the
> >cells and a single sample preparation only captures the latter.
> >
> >On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
> >> Dear All,
> >>
> >> Question:
> >>
> >> We are isolating leukocyte subsets to measure and compare relative
> >> levels of
> expression
> >> of certain antigens.  For example, there are three subsets
> within a
> >> bivariate dot
> plot;
> >> gated on R1, R2 and R3 respectively, and we would like to
> >> statistically analyze the relative mean fluorescence
> intensities of a
> >> biomarker, among the subsets.
> >>
> >> To get statistically comparable sample sizes among these
> subsets, we
> >> are running the
> same
> >> tube three times and changing the storage criteria to 500
> events for
> >> each subset (example, the first run is 500 events of R1,
> the second
> >> 500 of R2, and the third is
> 500
> >> of R3).  Instead of repeating the same tube three times,
> and wasting
> >> valuable sample,
> it
> >> seems like a good idea to "crop" a preexisting data file of, for
> >> example, 100,000
> total
> >> events, three times to get an identical sample size for all three
> >> gated subsets (R1,
> R2,
> >> and R3).
> >>
> >> Scientifically, this shouldn't be a problem, since flow cytometry
> >> data is collected randomly within the same sample tube.  Not only
> >> could we run one acquisition to get different monocyte subset
> >> populations, but also to statistically compare constant
> numbers
> >> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.
> However, I
> >> can see why some scientists might be uneasy with the idea of
> >> manipulating raw list-mode data.
> >>
> >> However, Since the data is collected randomly from the
> same sample,
> >> doing this should give exactly the same readings as if we just
> >> collected less events, since we would
> only
> >> be cropping (from stack-collected data) the most recent events
> >> collected.
> >>
> >> Currently, we are acquiring 3 different data files for
> each tube, and
> >> adjusting the acquisition and storage settings for each
> acquisition.
> >> Is there a way to perform a gate-specific data cropping
> function with
> >> any current flow cytometry data analysis software?
> >>
> >> Kind Regards,
> >>
> >> Stevan Lauriault
> >>
> >> ________________________________________________________________
> >> Sent via the WebMail system at lauriault.com
> >
> >--
> >Byron Ellis (byron.ellis@gmail.com)
> >"Oook" -- The Librarian
>
> ________________________________________________________________
> Sent via the WebMail system at lauriault.com

Received on Thu Feb 8 14:38:00 2007
*    This message: [ Message body ]
*    Next message: Byron Ellis: "Re: gate-specific data cropping"
*    Previous message: Joanne Lannigan: "Live/Dead Stain Kit Correction"
*    Maybe in reply to: Stevan Lauriault: "gate-specific data cropping"
*    Next in thread: Stevan Lauriault: "Re: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Byron Ellis <bcellis@stanford.edu>
Date: Wed Feb 07 2007 - 19:21:28 EST
On 2/7/07, Stevan Lauriault <stevan@lauriault.com> wrote:
> Hi and thanks,
>
> Since we want to directly compare MFIs (in FL2) between any two subsets (R1 vs. R3)
that are isolated on a bivariate dot plot (FL1 vs. FL4), doing so in
separate sample
tubes would introduce the extra probability of experimental error
between sample tubes.
Directly comparing the subsets from the same sample tube, and even
better, the same data
set, would eliminate this extra unknown.

It doesn't necessarily eliminate the unknown, it may just keep you
from finding out about it. If you were to prepare one sample on
Monday, see significant differences, celebrate, etc and then on
Wednesday prepare another sample where you didn't you'd probably want
to know that (and figure out why). Simply taking the FACS tube off the
cytometer and putting it back on won't give you that information. Now,
would I be surprised if that actually happened in your case? Yes.
Would I do replicates anyway? Yes.

> Let us say we have acquired 100,000 total events (stained with 3 fluorochromes,
measured in FL1, FL2, and FL4 respectively).  We are using a bivariate
dot plot of FL1
vs. FL4 in which we are isolating 3 subsets (R1, R2, and R3) based on
their relative
expressions of FL1 vs. FL4.  We then want to compare the MFIs, as
measured in FL2, among
these subsets.    Within those 100,000 total events, there are 500 of
R1, 700 of R2 and
1200 of R3.

> If we crop the 100,000 total events to 75,000 total events (from the top in
stack-collected data), there will become exactly 500 events in the R2
region.  If we crop
the 100,000 total events to 40,000 total events, there will become 500
events in R3.

> Now the three populations; R1, R2, and R3 each have exactly 500 total events, and we
can directly compare MFIs among the subsets that have identical sample
sizes.  We could
also then say that, when comparing means between these subsets under
identical
experimental conditions, Rx gives a consistently higher fluorescent
signal than Ry.

Well, depending on what you're doing (you've never said how you intend
to compare means), equal sample sizes is not particularly required so
there's no particular reason to cut the data to obtain equal sample
sizes. For example, one-way ANOVA (or one-way ANOVA with repeated
measure in the event that you chose to do _real_ replicates), which
simply says "they're different" (there are other tests, variants of
one-sided t-tests essentially, that give you directionality statements
such as mu_{R_1} > mu_{R_2} ). In this case your assumptions are:

1. Each group is independent
2. Normality of group populations (or at least "close enough" to
Normal)
3. The _population_ variances of the dependent variable for each group
are equal (or pretty close). (Actually check this. It would be
unsurprising to encounter large differences in the population
variances among your different groups).

Like I say, it depends a bit on what you intend to do for your
analysis. For example, _two_-way ANOVA actually expects equal sample
sizes.

> Is this a reasonable strategy?  Is there any software available that can perform this
function?

On an FCS file directly? Probably not (neither the manipulation of the
flow data nor the testing). Once you've got the data out of FCS form
and appropriately labeled with group membership or split into separate
files or something similar, then any reasonable statistics package
(Excel is not included in the list of reasonable statistics packages)
can perform the statistical tests.

Personally, I use R (http://www.r-project.org) for analyzing all the
flow data I have, but it can be intimidating for new users (though
extremely powerful once you learn to use it). There are two packages
in R for manipulating flow data at the moment (prada and rflowcyt),
available through the Bioconductor Project
(http://www.bioconductor.org) that can actually read in and manipulate
FCS data directly or slightly manipulated data from say FlowJo (so you
can do your gating there for example). I'm also part of a group made
up of the people who did rflowcyt and prada that are making a combined
package of the best bits of both (and some other new bits) that we
expect to be available in the next Bioconductor release (probably
sometime in April).

Hope that helps,

Byron

> Kind Regards,
>
> Stevan Lauriault
>
> ---------- Original Message ----------------------------------
> From: "Byron Ellis" <bcellis@stanford.edu>
> Date:  Tue, 6 Feb 2007 12:17:35 -0800
>
> >Speaking as a statistician, I would not count running the same tube 3
> >times or simply cutting the FCS file (the two are equivalent) as three
> >replicates so I wouldn't do either to achieve what you want (though I
> >can imagine situations where you would resample to calculate
> >statistics). To get three replicates you would have to prepare three
> >separate samples---you're interested in the variability of the mean
> >due to experimental error as well as the biological variability of the
> >cells and a single sample preparation only captures the latter.
> >
> >On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
> >> Dear All,
> >>
> >> Question:
> >>
> >> We are isolating leukocyte subsets to measure and compare relative levels of
expression
> >> of certain antigens.  For example, there are three subsets within a bivariate dot
plot;
> >> gated on R1, R2 and R3 respectively, and we would like to statistically analyze the
> >> relative mean fluorescence intensities of a biomarker, among the subsets.
> >>
> >> To get statistically comparable sample sizes among these subsets, we are running the
same
> >> tube three times and changing the storage criteria to 500 events for each subset
> >> (example, the first run is 500 events of R1, the second 500 of R2, and the third is
500
> >> of R3).  Instead of repeating the same tube three times, and wasting valuable
sample, it
> >> seems like a good idea to "crop" a preexisting data file of, for example, 100,000
total
> >> events, three times to get an identical sample size for all three gated subsets (R1,
R2,
> >> and R3).
> >>
> >> Scientifically, this shouldn't be a problem, since flow cytometry data is collected
> >> randomly within the same sample tube.  Not only could we run one acquisition to get
> >> different monocyte subset populations, but also to statistically compare constant
numbers
> >> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.    However, I can see why
some
> >> scientists might be uneasy with the idea of manipulating raw list-mode data.
> >>
> >> However, Since the data is collected randomly from the same sample, doing this
should
> >> give exactly the same readings as if we just collected less events, since we would
only
> >> be cropping (from stack-collected data) the most recent events collected.
> >>
> >> Currently, we are acquiring 3 different data files for each tube, and adjusting the
> >> acquisition and storage settings for each acquisition.  Is there a way to perform a
> >> gate-specific data cropping function with any current flow cytometry data analysis
> >> software?
> >>
> >> Kind Regards,
> >>
> >> Stevan Lauriault
> >>
> >> ________________________________________________________________
> >> Sent via the WebMail system at lauriault.com
> >
> >--
> >Byron Ellis (byron.ellis@gmail.com)
> >"Oook" -- The Librarian
>
> ________________________________________________________________
> Sent via the WebMail system at lauriault.com

--
Byron Ellis (byron.ellis@gmail.com)
"Oook" -- The Librarian
Received on Thu Feb 8 14:58:00 2007
*    This message: [ Message body ]
*    Next message: Kathy Heel: "Sorting RGCs"
*    Previous message: Nebe-Von-Caron, G: "RE: gate-specific data
cropping"
*    In reply to: Stevan Lauriault: "Re: gate-specific data cropping"
*    Next in thread: Nebe-Von-Caron, G: "RE: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Maybe in
reply to ] [ Next in thread ] [ Replies ]
From: Stevan Lauriault <stevan@lauriault.com>
Date: Wed Feb 07 2007 - 10:16:03 EST
Hi and thanks,

Since we want to directly compare MFIs (in FL2) between any two
subsets (R1 vs. R3) that
are isolated on a bivariate dot plot (FL1 vs. FL4), doing so in
separate sample tubes
would introduce the extra probability of experimental error between
sample tubes.
Directly comparing the subsets from the same sample tube, and even
better, the same data
set, would eliminate this extra unknown.

Let us say we have acquired 100,000 total events (stained with 3
fluorochromes, measured
in FL1, FL2, and FL4 respectively).  We are using a bivariate dot plot
of FL1 vs. FL4 in
which we are isolating 3 subsets (R1, R2, and R3) based on their
relative expressions of
FL1 vs. FL4.  We then want to compare the MFIs, as measured in FL2,
among these subsets.
Within those 100,000 total events, there are 500 of R1, 700 of R2 and
1200 of R3.

If we crop the 100,000 total events to 75,000 total events (from the
top in
stack-collected data), there will become exactly 500 events in the R2
region.  If we crop
the 100,000 total events to 40,000 total events, there will become 500
events in R3.

Now the three populations; R1, R2, and R3 each have exactly 500 total
events, and we can
directly compare MFIs among the subsets that have identical sample
sizes.  We could also
then say that, when comparing means between these subsets under
identical experimental
conditions, Rx gives a consistently higher fluorescent signal than Ry.

Is this a reasonable strategy?    Is there any software available that
can perform this
function?

Kind Regards,

Stevan Lauriault

---------- Original Message ----------------------------------
From: "Byron Ellis" <bcellis@stanford.edu>
Date:  Tue, 6 Feb 2007 12:17:35 -0800

>Speaking as a statistician, I would not count running the same tube 3
>times or simply cutting the FCS file (the two are equivalent) as three
>replicates so I wouldn't do either to achieve what you want (though I
>can imagine situations where you would resample to calculate
>statistics). To get three replicates you would have to prepare three
>separate samples---you're interested in the variability of the mean
>due to experimental error as well as the biological variability of the
>cells and a single sample preparation only captures the latter.
>
>On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
>> Dear All,
>>
>> Question:
>>
>> We are isolating leukocyte subsets to measure and compare relative levels of
expression
>> of certain antigens.  For example, there are three subsets within a bivariate dot
plot;
>> gated on R1, R2 and R3 respectively, and we would like to statistically analyze the
>> relative mean fluorescence intensities of a biomarker, among the subsets.
>>
>> To get statistically comparable sample sizes among these subsets, we are running the
same
>> tube three times and changing the storage criteria to 500 events for each subset
>> (example, the first run is 500 events of R1, the second 500 of R2, and the third is
500
>> of R3).  Instead of repeating the same tube three times, and wasting valuable sample,
it
>> seems like a good idea to "crop" a preexisting data file of, for example, 100,000
total
>> events, three times to get an identical sample size for all three gated subsets (R1,
R2,
>> and R3).
>>
>> Scientifically, this shouldn't be a problem, since flow cytometry data is collected
>> randomly within the same sample tube.  Not only could we run one acquisition to get
>> different monocyte subset populations, but also to statistically compare constant
numbers
>> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.  However, I can see why some
>> scientists might be uneasy with the idea of manipulating raw list-mode data.
>>
>> However, Since the data is collected randomly from the same sample, doing this should
>> give exactly the same readings as if we just collected less events, since we would
only
>> be cropping (from stack-collected data) the most recent events collected.
>>
>> Currently, we are acquiring 3 different data files for each tube, and adjusting the
>> acquisition and storage settings for each acquisition.  Is there a way to perform a
>> gate-specific data cropping function with any current flow cytometry data analysis
>> software?
>>
>> Kind Regards,
>>
>> Stevan Lauriault
>>
>> ________________________________________________________________
>> Sent via the WebMail system at lauriault.com
>
>--
>Byron Ellis (byron.ellis@gmail.com)
>"Oook" -- The Librarian

________________________________________________________________
Sent via the WebMail system at lauriault.com
Received on Wed Feb 7 20:38:00 2007
*    This message: [ Message body ]
*    Next message: Wilson Mandala: "Re: detection of Tregs in PHA/PMA
stimulated cultures of CD T cells"
*    Previous message: Matthew Hanson: "Unique opportunity for the right
person at the UW-Madison!"
*    Maybe in reply to: Stevan Lauriault: "gate-specific data cropping"
*    Next in thread: Byron Ellis: "Re: gate-specific data cropping"
*    Reply: Byron Ellis: "Re: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Byron Ellis <bcellis@stanford.edu>
Date: Tue Feb 06 2007 - 15:17:35 EST
Speaking as a statistician, I would not count running the same tube 3
times or simply cutting the FCS file (the two are equivalent) as three
replicates so I wouldn't do either to achieve what you want (though I
can imagine situations where you would resample to calculate
statistics). To get three replicates you would have to prepare three
separate samples---you're interested in the variability of the mean
due to experimental error as well as the biological variability of the
cells and a single sample preparation only captures the latter.

On 2/5/07, Stevan Lauriault <stevan@lauriault.com> wrote:
> Dear All,
>
> Question:
>
> We are isolating leukocyte subsets to measure and compare relative levels of expression
> of certain antigens.    For example, there are three subsets within a bivariate dot plot;
> gated on R1, R2 and R3 respectively, and we would like to statistically analyze the
> relative mean fluorescence intensities of a biomarker, among the subsets.
>
> To get statistically comparable sample sizes among these subsets, we are running the
same
> tube three times and changing the storage criteria to 500 events for each subset
> (example, the first run is 500 events of R1, the second 500 of R2, and the third is 500
> of R3).  Instead of repeating the same tube three times, and wasting valuable sample,
it
> seems like a good idea to "crop" a preexisting data file of, for example, 100,000 total
> events, three times to get an identical sample size for all three gated subsets (R1,
R2,
> and R3).
>
> Scientifically, this shouldn't be a problem, since flow cytometry data is collected
> randomly within the same sample tube.  Not only could we run one acquisition to get
> different monocyte subset populations, but also to statistically compare constant
numbers
> of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.  However, I can see why some
> scientists might be uneasy with the idea of manipulating raw list-mode data.
>
> However, Since the data is collected randomly from the same sample, doing this should
> give exactly the same readings as if we just collected less events, since we would only
> be cropping (from stack-collected data) the most recent events collected.
>
> Currently, we are acquiring 3 different data files for each tube, and adjusting the
> acquisition and storage settings for each acquisition.  Is there a way to perform a
> gate-specific data cropping function with any current flow cytometry data analysis
> software?
>
> Kind Regards,
>
> Stevan Lauriault
>
> ________________________________________________________________
> Sent via the WebMail system at lauriault.com

--
Byron Ellis (byron.ellis@gmail.com)
"Oook" -- The Librarian
Received on Wed Feb 7 18:58:00 2007
*    This message: [ Message body ]
*    Next message: RAJA ALAMELU: "Storage of fixed cells before
acquisition"
*    Previous message: Eric Van Buren: "Re: gate-specific data cropping"
*    In reply to: Stevan Lauriault: "gate-specific data cropping"
*    Next in thread: Stevan Lauriault: "Re: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Eric Van Buren <eric.vanburen@wayne.edu>
Date: Wed Feb 07 2007 - 10:57:01 EST
Stevan,

It's not exactly what you're looking for, but the easiest "off the
shelf" solution may
be to acquire time as a parameter. Or, if your software allows, use
the simulated time
parameter. Gate on time empirically to produce the the desired number
of events in
each region.

As you say, the sampling is random, so it shouldn't matter which "time
slice" you choose.
However, to keep a uniform protocol you may want to always start your
time gate with time
equals zero, i.e. starting at the beginning of the list mode file.
This should minimize
any time-related artifacts, such as sample settling, sample/sheath dye
equilibrium,
exposure to room light, temperature, etc.

--Eric

>Dear All,
>
>Question:
>
>We are isolating leukocyte subsets to measure and compare relative levels of expression
>of certain antigens.  For example, there are three subsets within a bivariate dot plot;
>gated on R1, R2 and R3 respectively, and we would like to statistically analyze the
>relative mean fluorescence intensities of a biomarker, among the subsets.
>
>To get statistically comparable sample sizes among these subsets, we are running the
same
>tube three times and changing the storage criteria to 500 events for each subset
>(example, the first run is 500 events of R1, the second 500 of R2, and the third is 500
>of R3).  Instead of repeating the same tube three times, and wasting valuable sample, it
>seems like a good idea to "crop" a preexisting data file of, for example, 100,000 total
>events, three times to get an identical sample size for all three gated subsets (R1, R2,
>and R3).
>
>Scientifically, this shouldn't be a problem, since flow cytometry data is collected
>randomly within the same sample tube.    Not only could we run one acquisition to get
>different monocyte subset populations, but also to statistically compare constant
numbers
>of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.  However, I can see why some
>scientists might be uneasy with the idea of manipulating raw list-mode data.
>
>However, Since the data is collected randomly from the same sample, doing this should
>give exactly the same readings as if we just collected less events, since we would only
>be cropping (from stack-collected data) the most recent events collected.
>
>Currently, we are acquiring 3 different data files for each tube, and adjusting the
>acquisition and storage settings for each acquisition. Is there a way to perform a
>gate-specific data cropping function with any current flow cytometry data analysis
>software?
>
>Kind Regards,
>
>Stevan Lauriault
>
>________________________________________________________________
>Sent via the WebMail system at lauriault.com

Eric Van Buren <eric.vanburen@wayne.edu>
Manager, Flow Cytometry Core Facility
Karmanos Cancer Institute
Detroit, Michigan, USA
Received on Wed Feb 7 18:38:01 2007
*    This message: [ Message body ]
*    Next message: Byron Ellis: "Re: gate-specific data cropping"
*    Previous message: RAJA ALAMELU: "FACSort Macintosh conked off!"
*    In reply to: Stevan Lauriault: "gate-specific data cropping"
*    Next in thread: Byron Ellis: "Re: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

gate-specific data cropping
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Next in
thread ] [ Replies ]
From: Stevan Lauriault <stevan@lauriault.com>
Date: Mon Feb 05 2007 - 13:56:18 EST
Dear All,

Question:

We are isolating leukocyte subsets to measure and compare relative
levels of expression
of certain antigens.  For example, there are three subsets within a
bivariate dot plot;
gated on R1, R2 and R3 respectively, and we would like to
statistically analyze the
relative mean fluorescence intensities of a biomarker, among the
subsets.

To get statistically comparable sample sizes among these subsets, we
are running the same
tube three times and changing the storage criteria to 500 events for
each subset
(example, the first run is 500 events of R1, the second 500 of R2, and
the third is 500
of R3).  Instead of repeating the same tube three times, and wasting
valuable sample, it
seems like a good idea to "crop" a preexisting data file of, for
example, 100,000 total
events, three times to get an identical sample size for all three
gated subsets (R1, R2,
and R3).

Scientifically, this shouldn't be a problem, since flow cytometry data
is collected
randomly within the same sample tube.  Not only could we run one
acquisition to get
different monocyte subset populations, but also to statistically
compare constant numbers
of monocytes, PMNs, lymphocytes, lymphocyte subsets, etc.  However, I
can see why some
scientists might be uneasy with the idea of manipulating raw list-mode
data.

However, Since the data is collected randomly from the same sample,
doing this should
give exactly the same readings as if we just collected less events,
since we would only
be cropping (from stack-collected data) the most recent events
collected.

Currently, we are acquiring 3 different data files for each tube, and
adjusting the
acquisition and storage settings for each acquisition.    Is there a way
to perform a
gate-specific data cropping function with any current flow cytometry
data analysis
software?

Kind Regards,

Stevan Lauriault

________________________________________________________________
Sent via the WebMail system at lauriault.com
Received on Tue Feb 6 13:18:00 2007
*    This message: [ Message body ]
*    Next message: Beverly Barton: "Re: Equipment Survey"
*    Previous message: Lora Barsky: "Re: Cell Quest pro and non CellQuest
data"
*    Next in thread: Eric Van Buren: "Re: gate-specific data cropping"
*    Reply: Eric Van Buren: "Re: gate-specific data cropping"
*    Reply: Byron Ellis: "Re: gate-specific data cropping"
*    Maybe reply: Stevan Lauriault: "Re: gate-specific data cropping"
*    Maybe reply: Nebe-Von-Caron, G: "RE: gate-specific data cropping"
*    Maybe reply: Stevan Lauriault: "Re: gate-specific data cropping"
*    Maybe reply: VSH Tech Support: "RE: gate-specific data cropping"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

RE: DNA analysis software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Novo, David <david.novo@denovosoftware.com>
Date: Fri Feb 16 2007 - 19:05:22 EST
Hello Ibtissam,

Multicycle is a very commonly used DNA analysis program. It can
automatically detect the number of aneuploid populations that you have
(if any) and runs them through several different models with different
fitting parameters to help you determine which is the best one for
your
data. It also has a wide range of debris and aggregate compensation to
allow it to be used with a wide variety of sample preparation methods.

Multicycle has just been incorporated as a plug in module to FCS
Express, so that you get the benefits of the high end DNA analysis as
well as the ease of use and gating/presentation abilities of FCS
Express. It really makes DNA analysis a snap.

There is some information available at
http://www.denovosoftware.com/site/Multicycleplugin.shtml

-Dave

-----------------------------------

David Novo

President

De Novo Software

david.novo@denovosoftware.com

________________________________

From: Ibtissam Abdul-Jabbar [mailto:iajabbar@cicr.uq.edu.au]
Sent: Wednesday, February 14, 2007 8:41 PM
To: cyto-inbox
Subject: DNA analysis software

Dear All, before buying software to analyse DNA on PC, I would like to
get your opinion. I already have ModFit for Macintosh.

What are you using and what do you recommend for research purposes.

Is MultiCycle Av the one of choice?

I appreciate your comments.

Ibtissam A Jabbar (PhD)

Manager of the FACS facilities

Diamantina Institute for Cancer, Immunology and Metabolic Medicine
(DI)

The University of Queensland

Level 4 R Wing

Princess Alexandra Hospital

Ipswich Rd Buranda QLD 4102

Australia

Ph: 07 3240 5945

Fax: 07 3240 5946

Mob: 0401154744

Received on Mon Feb 19 13:38:00 2007
*    This message: [ Message body ]
*    Next message: mmodel@kent.edu: "presenting flow data"
*    Previous message: Derek Davies: "Re: tecnicad el ciclo celular"
*    In reply to: Ibtissam Abdul-Jabbar: "DNA analysis software"
*    Next in thread: VSH Tech Support: "RE: DNA analysis software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

DNA analysis software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Next in
thread ] [ Replies ]
From: Ibtissam Abdul-Jabbar <iajabbar@cicr.uq.edu.au>
Date: Wed Feb 14 2007 - 23:41:15 EST
Dear All, before buying software to analyse DNA on PC, I would like to
get your opinion. I already have ModFit for Macintosh.

What are you using and what do you recommend for research purposes.

Is MultiCycle Av the one of choice?

I appreciate your comments.

Ibtissam A Jabbar (PhD)

Manager of the FACS facilities

Diamantina Institute for Cancer, Immunology and Metabolic Medicine
(DI)

The University of Queensland

Level 4 R Wing

Princess Alexandra Hospital

Ipswich Rd Buranda QLD 4102

Australia

Ph: 07 3240 5945

Fax: 07 3240 5946

Mob: 0401154744

Received on Thu Feb 15 12:38:00 2007
*    This message: [ Message body ]
*    Next message: moorej@mail.MED.UPENN.EDU: "Fwd: Re: early apoptotic
cells"
*    Previous message: FACSLAB: "Northern Flow Group (UK)"
*    Next in thread: Novo, David: "RE: DNA analysis software"
*    Reply: Novo, David: "RE: DNA analysis software"
*    Reply: VSH Tech Support: "RE: DNA analysis software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
FACSCalibur - developing software for Macintosh
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ]
From: Simon Crase <Simon.Crase@invetech.com.au>
Date: Tue Feb 13 2007 - 16:32:34 EST
I've developed software to analyze data from a FACSCalibur, and our
client has asked whether we can port it to run on the FACSCalibur
itself. I understand the FACSCalibur includes a Macintosh. I'm
interested in knowing whether anyone has done this before, especially
with Java, and what pitfalls they encountered.

Simon A. Crase

Invetech Pty Ltd
Private Bag 44
495 Blackburn Road
Mount Waverley    Vic  3149

Phone:    61 3 9211 7933
Mobile: 0424 782 725
Fax:    61 3 9211 7702 (facsimile)
e-mail: simon.crase@invetech.com.au
___________________________________________________________
IMPORTANT - This email and any attachments may be confidential. Any
retransmissions, dissemination or other use of these materials by
persons or entities other than the intended recipient is prohibited.
If
received in error, please contact us and delete all copies. Before
opening or using attachments, check them for viruses and defects. Our
liability is limited to resupplying any affected attachments. [Any
representations or opinions expressed in this e.mail are those of the
individual sender, and not necessarily those of Vision Systems
Limited].
Received on Wed Feb 14 16:18:00 2007
*    This message: [ Message body ]
*    Next message: William King: "Re: early apoptotic cells"
*    Previous message: gharagozlo@sums.ac.ir: "correlation between cell
cycle and cell proliferation, a question"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Flow analysis software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ]
From: Xiangle Sun <sunxiangle@yahoo.com>
Date: Wed Sep 12 2007 - 17:12:44 EDT
Hi, Flowers,
We just got BD LSRII flow cytometer with FACSDiva
software. I know Flowjo is a popular software and some
people use FlowJo instead of FACSDiva to do data
analysis even it comes with instrument.
My questions are:
1. What are the advantages of FlowJo and FACSDiva.
Then is it worth of purchasing FlowJo to do analysis?
2. How about the feature of FlowJo and FACSDiva on DNA
cycle analysis?
3. Are there any other better analysis softwares?
either for multicolor phenotyping, DNA cycle or both?

Any comments that based on your experience will be
greatly appreciated!

Xiangle Sun

____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos &
more.
http://mobile.yahoo.com/go?refer=1GNXIC
Received on Thu Sep 13 11:18:00 2007
*    This message: [ Message body ]
*    Next message: Jose Benito: "malaria"
*    Previous message: Ray Hester: "entire membrane fluor vs capped -
equally bright by FACS?"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

RE: CFSE proliferation software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Maybe in
reply to ]
From: user facs_copy <facs_copy@wehi.EDU.AU>
Date: Wed Sep 19 2007 - 02:03:28 EDT
Michael,

Depends what you mean by "analyze".  If you mean just to extract cell
numbers at each division state, we use our own Weasel program for that
(see http://www.wehi.edu.au/cytometry/WEASELv2.html , scroll to the
bottom
of the page).  We also have a proliferation modelling program,
CytonCalculator, that can take that proliferation data and fit a model
calculation to it (see
http://www.wehi.edu.au/WEHI_Groups/indexworkgroups.php?id=115 for the
entry point that describes the process).  CytonCalculator may be
downloaded free.  You'll find the download link on that page.

Frank Battye.

> From: Kalos, Michael
> Sent: Thursday, September 13, 2007 5:39 PM

> No doubt this has been brought up before:  I am looking for software
> recommendations to analyze data for measuring proliferation using CFSE.
> Our data is acquired on an FC500 and our computers are PC-based.

   |    |     < The Cytometry Laboratory
    \__/  <<<<< The Walter & Eliza Hall Institute
------!!<<<<<<<< Post Office, Royal Melbourne Hospital
    /!!\  <<<<< Victoria 3050, Australia
   o !! \     < ph: 61_3_9345 2541, fax: 61_3_9347 0852
Received on Wed Sep 19 11:38:00 2007
*    This message: [ Message body ]
*    Next message: pearly.yong.j.a@nhc.com.sg: "Histogram overlay and
exporting fcs 2.0 files question"
*    Previous message: Maria Laura: "RE: single cell sorting"
*    Maybe in reply to: Kalos, Michael: "RE: CFSE proliferation software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
RE: CFSE proliferation software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: <moorej@mail.MED.UPENN.EDU>
Date: Mon Sep 17 2007 - 19:20:03 EDT
I also agree.  We do a lot of proliferation studies and have found
that
Proliferation Wizard on Modfit is very good.

Jonni

Quoting James F George <jgeorge@uab.edu>:

> I have found the Modfit software from Verity to be quite useful for
> this, and it integrates with Winlist rather nicely, if you have it.  Don
> at Verity has been very helpful over the years in helping us implement
> the software for routine analyses.
>
> I highly recommend this company.
>
> I have no financial interest in Verity.  I am just a long-time user.
>
> James F. George, PhD    |  Professor
> Division of Cardiothoracic Surgery  |  University of Alabama at
> Birmingham
>
> 701 South 19th St.  |  Birmingham, AL 35294
>
> Phone: (205) 934-4261  |  Fax: (205) 975-0085
>
> Email: jgeorge@uab.edu <mailto:jgeorge@uab.edu>
>
> UAB HEALTH SYSTEM
> Medicine that touches the world
>
> ________________________________
>
> From: Kalos, Michael [mailto:MKalos@coh.org]
> Sent: Thursday, September 13, 2007 5:39 PM
> To: cyto-inbox
> Subject: RE: CFSE proliferation software
>
> No doubt this has been brought up before:  I am looking for software
> recommendations to analyze data for measuring proliferation using CFSE.
> Our data is acquired on an FC500 and our computers are PC-based.
>
> Thanks in advance,
>
> Michael Kalos
>
> Michael Kalos, Ph.D.
> Director, Clinical Immunobiology Correlative Studies Laboratory
> Division of Cancer Immunotherapeutics and Tumor Immunology
> Division of Hematology and Hematopoietic Cell Transplantation
> City of Hope
> 1500 East Duarte Road,
> Duarte, CA 91010-5004
> mkalos@coh.org
> Ph:    626.256.4673, ext. 62126
> Fax: 626.301.8261
>
> "EMF <COH.org>" made the following annotations.
> ------------------------------------------------------------------------
> ------
>
> SECURITY/CONFIDENTIALITY WARNING: This message and any attachments are
> intended solely for the individual or entity to which they are
> addressed. This communication may contain information that is
> privileged, confidential, or exempt from disclosure under applicable law
> (e.g., personal health information, research data, financial
> information). Because this e-mail has been sent without encryption,
> individuals other than the intended recipient may be able to view the
> information, forward it to others or tamper with the information without
> the knowledge or consent of the sender. If you are not the intended
> recipient, or the employee or person responsible for delivering the
> message to the intended recipient, any dissemination, distribution or
> copying of the communication is strictly prohibited. If you received the
> communication in error, please notify the sender immediately by replying
> to this message and deleting the message and any accompanying files from
> your system. If, due to the security risks, you do not wish to receive
> further communications via e-mail, please reply to this message and
> inform the sender that you do not wish to receive further e-mail from
> the sender.
>
> ========================================================================
> ======

--
Received on Tue Sep 18 13:18:00 2007
*    This message: [ Message body ]
*    Next message: Bryant, Jenny (NSW): "Phenol Red & Luminex"
*    Previous message: O'Toole, P: "Hands-on Course in York 2008"
*    In reply to: James F George: "RE: CFSE proliferation software"
*    Next in thread: user facs_copy: "RE: CFSE proliferation software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
RE: CFSE proliferation software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ] [ Replies ]
From: James F George <jgeorge@uab.edu>
Date: Mon Sep 17 2007 - 09:37:30 EDT
I have found the Modfit software from Verity to be quite useful for
this, and it integrates with Winlist rather nicely, if you have it.
Don
at Verity has been very helpful over the years in helping us implement
the software for routine analyses.

I highly recommend this company.

I have no financial interest in Verity.  I am just a long-time user.

James F. George, PhD  |  Professor
Division of Cardiothoracic Surgery  |  University of Alabama at
Birmingham

701 South 19th St.  |  Birmingham, AL 35294

Phone: (205) 934-4261  |  Fax: (205) 975-0085

Email: jgeorge@uab.edu <mailto:jgeorge@uab.edu>

UAB HEALTH SYSTEM
Medicine that touches the world

________________________________

From: Kalos, Michael [mailto:MKalos@coh.org]
Sent: Thursday, September 13, 2007 5:39 PM
To: cyto-inbox
Subject: RE: CFSE proliferation software

No doubt this has been brought up before:  I am looking for software
recommendations to analyze data for measuring proliferation using
CFSE.
Our data is acquired on an FC500 and our computers are PC-based.

Thanks in advance,

Michael Kalos

Michael Kalos, Ph.D.
Director, Clinical Immunobiology Correlative Studies Laboratory
Division of Cancer Immunotherapeutics and Tumor Immunology
Division of Hematology and Hematopoietic Cell Transplantation
City of Hope
1500 East Duarte Road,
Duarte, CA 91010-5004
mkalos@coh.org
Ph:   626.256.4673, ext. 62126
Fax: 626.301.8261

"EMF <COH.org>" made the following annotations.
------------------------------------------------------------------------
------

SECURITY/CONFIDENTIALITY WARNING: This message and any attachments are
intended solely for the individual or entity to which they are
addressed. This communication may contain information that is
privileged, confidential, or exempt from disclosure under applicable
law
(e.g., personal health information, research data, financial
information). Because this e-mail has been sent without encryption,
individuals other than the intended recipient may be able to view the
information, forward it to others or tamper with the information
without
the knowledge or consent of the sender. If you are not the intended
recipient, or the employee or person responsible for delivering the
message to the intended recipient, any dissemination, distribution or
copying of the communication is strictly prohibited. If you received
the
communication in error, please notify the sender immediately by
replying
to this message and deleting the message and any accompanying files
from
your system. If, due to the security risks, you do not wish to receive
further communications via e-mail, please reply to this message and
inform the sender that you do not wish to receive further e-mail from
the sender.

========================================================================
======
Received on Mon Sep 17 14:18:01 2007
*    This message: [ Message body ]
*    Next message: pautissi@bidmc.harvard.edu: "[RAAM '07 - Patrick
Autissier] Race report, video and photos"
*    Previous message: Konz, Richard: "New England Cytometry Meeting
Registration"
*    In reply to: Kalos, Michael: "RE: CFSE proliferation software"
*    Next in thread: moorej@mail.MED.UPENN.EDU: "RE: CFSE proliferation
software"
*    Reply: moorej@mail.MED.UPENN.EDU: "RE: CFSE proliferation software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

GUAVA Files
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Maria Laura <mcabanas@gemabiotech.com>
Date: Fri Sep 14 2007 - 16:20:15 EDT

Hi!

I´ve run  Reticulocite samples using Guava EasyCyte Citometer . I want
to
analyze Guava Files using Summit Software (MoFlo)  and I don´t see the
same
Plots.

Guava saves files FCS 3.0 and 2.0 .  Summit can only read 2.0 but the
Plots
shows very different.

I´ve analyzed FCS files from other different Citometers using the
Summit
software, and never had a problem.

Is there any way to convert the files?

Thanks in advance

Laura Cabanas

Buenos Aires

Argentina

Received on Mon Sep 17 13:38:00 2007
*    This message: [ Message body ]
*    Next message: Konz, Richard: "New England Cytometry Meeting
Registration"
*    Previous message: Sawyer, Tom: "GLIIFCA GOLF OUTING"
*    In reply to: Kalos, Michael: "RE: CFSE proliferation software"
*    Next in thread: James F George: "RE: CFSE proliferation software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
RE: CFSE proliferation software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ] [ Replies ]
From: Kalos, Michael <MKalos@coh.org>
Date: Thu Sep 13 2007 - 18:38:56 EDT
No doubt this has been brought up before:  I am looking for software
recommendations to analyze data for measuring proliferation using
CFSE.
Our data is acquired on an FC500 and our computers are PC-based.

Thanks in advance,

Michael Kalos

Michael Kalos, Ph.D.
Director, Clinical Immunobiology Correlative Studies Laboratory
Division of Cancer Immunotherapeutics and Tumor Immunology
Division of Hematology and Hematopoietic Cell Transplantation
City of Hope
1500 East Duarte Road,
Duarte, CA 91010-5004
mkalos@coh.org
Ph:   626.256.4673, ext. 62126
Fax: 626.301.8261

"EMF <COH.org>" made the following annotations.
------------------------------------------------------------------------------

SECURITY/CONFIDENTIALITY WARNING:  This message and any attachments
are intended solely for the individual or entity to which they are
addressed. This communication may contain information that is
privileged, confidential, or exempt from disclosure under applicable
law (e.g., personal health information, research data, financial
information). Because this e-mail has been sent without encryption,
individuals other than the intended recipient may be able to view the
information, forward it to others or tamper with the information
without the knowledge or consent of the sender. If you are not the
intended recipient, or the employee or person responsible for
delivering the message to the intended recipient, any dissemination,
distribution or copying of the communication is strictly prohibited.
If you received the communication in error, please notify the sender
immediately by replying to this message and deleting the message and
any accompanying files from your system. If, due to the security
risks, you do not wish to receive further communications via e-mail,
please reply to this message and inform the sender that you do not
wish to receive further e-mail from the sender.
==============================================================================
Received on Fri Sep 14 13:58:00 2007
*    This message: [ Message body ]
*    Next message: Liza Bronner: "single cell sorting"
*    Previous message: Brian Lee: "Phenol Red Interference"
*    In reply to: Jose Benito: "malaria"
*    Next in thread: Maria Laura: "GUAVA Files"
*    Reply: Maria Laura: "GUAVA Files"
*    Reply: James F George: "RE: CFSE proliferation software"
*    Maybe reply: user facs_copy: "RE: CFSE proliferation software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
RE: Cell cycle software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ]
From: Tim Kute <tkute@wfubmc.edu>
Date: Wed Sep 19 2007 - 11:24:35 EDT
MODFIT

-----Original Message-----
From: Sara Bar-Yehuda [mailto:Sara@canfite.co.il]
Sent: Tuesday, September 18, 2007 9:43 AM
To: cyto-inbox
Subject: Cell cycle software

Dear All,

We are interested in purchasing a cell cycle software. We looked at
"MODFIT" and "MULTICYCLE". Which one will you recommend to use for
MAC?

Thank you in advance,

Sara/Renana

Sara Bar Yehuda, Ph.D.
Can-Fite BioPharma

10 Bareket st.
P.O.Box 7537
Petach-Tikva 49170
Israel
Tel: 972-3-9241114
Fax: 972-3-9249378
E-mail: sara@canfite.co.il
Received on Thu Sep 20 12:18:00 2007
*    This message: [ Message body ]
*    Next message: Sergey Dzekunov: "FACS on platelets"
*    Previous message: Andy Heath: "MDCK cells"
*    In reply to: Sara Bar-Yehuda: "Cell cycle software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Cell cycle software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ Next in
thread ] [ Replies ]
From: Sara Bar-Yehuda <Sara@canfite.co.il>
Date: Tue Sep 18 2007 - 09:43:06 EDT
Dear All,

We are interested in purchasing a cell cycle software. We looked at
"MODFIT" and
"MULTICYCLE". Which one will you recommend to use for MAC?

Thank you in advance,

Sara/Renana

Sara Bar Yehuda, Ph.D.
Can-Fite BioPharma

10 Bareket st.
P.O.Box 7537
Petach-Tikva 49170
Israel
Tel: 972-3-9241114
Fax: 972-3-9249378
E-mail: sara@canfite.co.il

*    Application/Octet-stream attachment: -
*    Application/Octet-stream attachment: -
<!-- attachment="02--" -->
Received on Tue Sep 18 14:18:00 2007
*    This message: [ Message body ]
*    Next message: Maria Laura: "RE: single cell sorting"
*    Previous message: Rachael Walker: "summary of replies: fluorescent
probes"
*    Next in thread: Tim Kute: "RE: Cell cycle software"
*    Reply: Tim Kute: "RE: Cell cycle software"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
New Flow Cytometry Website
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ]
From: Andy Riddell <Riddell@embl.de>
Date: Mon Oct 01 2007 - 04:16:59 EDT
Hi All,

We have developed a new Flow cytometry web site here at EMBL. The
link is:
www.fccf.embl.de/fccfweb

Our aim is to keep this site active, that is,  we want to add new
resources/news every 2 weeks. We would very much appreciate any
feedback or comments that you have regarding this site.

Best Regards,

Andy and Alexis.

Andy Riddell
Flow Cytometry Core Laboratory
EMBL Heidelberg
Meyerhofstrasse 1, 69117 Heidelberg, Germany
Tel: +49 [0] 6221 387-8341
Fax: +49 [0] 6221 387-8306

-- End --
Received on Mon Oct 1 10:58:00 2007
*    This message: [ Message body ]
*    Next message: enrico lugli: "intracellular TGF-beta and IL-10
detection"
*    Previous message: Darren Hickerson: "RE: FACS on platelets"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Cell cycle: FlowJo vs. ModFIT
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ]
From: Marko Marjanovic <mmarjano@irb.hr>
Date: Mon Oct 01 2007 - 10:43:15 EDT
Dear flowers,

A couple of days ago I turned to FlowJo (I'm really only a beginner
with
this software) for some cell cycle analysis because I wanted to try
something new (and better) than an old version of ModFIT I was
already
using with my FACSCalibur. Flowjo gives me more free handling in
determining Gaussian peaks of G1 and G2 than ModFIT which is great
for
some really distorted histograms that I get with some treatments of
my
cells, where ModFIT is usually inadequate (don't know if I used the
proper word to describe it). But then I found myself with a problem,
or
should I say a challenge. With ModFIT I always get the Sum of G1, S,
G2
phases as 100%, whether I have a lot or none <G1 and >G2 cells. In
flowjo, if I have a histogram with a lot of dead cells (usually in my
treated cells) the sum of the 3 phases is not a 100%, not even close,
and thus the data analyzed this way isn't comparable to ModFIT's
data,
or any older data I have. The real question is what should I do now?
Can
a flowjo be modified so that sum would always be 100%? I cannot
exclude
dead cells because it is a very important part of my data, and I
don't
want to overlook a clear error done by ModFIT in a few bad
histograms.
Or should I just analyze data in either one of the softwares and
consider it a good job?
My mind is troubled the most by the possibility that the rate of
subG1
cells could markedly influence the relation of the cell cycle phases.

??

Thanx, Marko

--
Marko Marjanovic, B.Sc.
Laboratory of Functional Genomics
Division of Molecular Medicine
Rudjer Boskovic Institute
Bijenicka 54, Zagreb, HR-10000
Phone: +385 1 4561111 (ext.1772)
E-mail: mmarjano@irb.hr
http://www.irb.hr/en/str/zmm/LABS/LFG/djelatnici/marko/
Received on Tue Oct 2 11:18:00 2007
*    This message: [ Message body ]
*    Next message: Moss, Delynn M. (CDC/CCID/NCZVED): "Users/Beckman
Coulter Altra"
*    Previous message: Vainshtein, Inna: "RE: Alexa Fluor conjugates"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: Using DIVA Exp Files in Flojo
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ] [ Replies ]
From: y.Isomoto <kyo3@cc.okayama-u.ac.jp>
Date: Sun Oct 14 2007 - 23:50:40 EDT
Hi Flowers

data Inspector/Keyword    OPEN

DElete NAme SampleID&PAtentID

 ----- Original Message -----
 From: Houston, Jim
 To: Cytometry Mailing List
 Sent: Thursday, October 11, 2007 1:16 AM
 Subject: Using DIVA Exp Files in Flojo

 We have been using the BD Diva Files for some time in FloJo.    I now
have
another problem.

 I know that DIVA uses the Specimen name when exporting files as FCS.
We
usually use the same Exp name and Specimen to make things less
complicated.

 Now I have a set of experiments that we run with different specimen
names
under 1 exp.  In FloJo you cannot seem to access the Specimen name
directly.
FloJo support was unable to help in this also.    BD support is slow at
best.

 If you have experience in this area please let me know some clues on
how
to handle this.

 I have also notice using the DIVA software that when you change some
user
keywords they do not export out.  Any idea with what is up with that?

 Still trying to get info from BD.

 All help/suggestions are appreciated.

 Jim Houston

------------------------------------------------------------------------------

 No virus found in this incoming message.
 Checked by AVG Free Edition.
 Version: 7.5.488 / Virus Database: 269.14.8/1064 - Release Date:
2007/10/11 15:09
Received on Mon Oct 15 13:58:00 2007
*    This message: [ Message body ]
*    Next message: Cyril Cohen: "Canto 2 vs. Cytomics FC500"
*    Previous message: Xincheng Zheng: "Toxicological study request"
*    In reply to: Houston, Jim: "Using DIVA Exp Files in Flojo"
*    Next in thread: FlowJo Technical Support - Maciej Simm: "Re: Using
DIVA Exp Files in Flojo"
*    Reply: FlowJo Technical Support - Maciej Simm: "Re: Using DIVA Exp
Files in Flojo"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
Re: Using DIVA Exp Files in Flojo
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: bunny <bunny@cotleur.com>
Date: Mon Oct 15 2007 - 12:53:01 EDT
Sounds like time for a DiVa listserv!

We have been only someowhat successful maintaining keyword info on
FSC3 export of DiVa data. In some samples, the info is there, others
it's stripped off.
(The DiVa manual actually says this information is removed upon FSC
export). So like many, we used the TUBE info to put cryptic info :
PT65_unstim_D3_004  etc, with the last 3 digits being the unique
file
number.
Like Dr Wilson, we name the experiments BC101507 (initials & date).
The problem we have is the WINDOWS SERVER our data travels through-
not flowjo! If I move the data to a flashdrive & put on my mac- the
file names are intact. If I put through the server we get  BC10$f_3_#
$005.fcs where most of the "combined" file name is stripped off.
Now,
if you put the files into FJ you can still use TUBE info to
determine
the correct filename, but its a pain.
I have also sent a lengthy email to a BD engineer asking for help
around this problem.

In the meantime, a workaround (of sorts):
label your Experiment with ONE letter. Put all your info in TUBE ID.
Export, then dump it all into a new folder that you've labelled with
what you originally called your experiment. (Which you can rename
after the export process).
In Flowjo, add the TUBEID to the workspace and you can use those
keywords to sort into groups.  Not the most elegant way to do
things,
but it streamlined data going though our servers (where we also
backup the data!) It's also much easier than opening file FCS files
in FJ simply ot figure out what each file contains.

(BTW- I also found sorting your list in FJ works best if sorted by
TIME COLLECTED since my tube info is not alphabetical)

bunny

ï¿1/4
Bunny Cotleur, M.S.
Lead Research Technologist, Dept of Neurosciences
Scientific Consultant, Flow Cytometry Core
Cleveland Clinic Foundation
Lerner Research Institute, NC30
9500 Euclid Avenue
Cleveland, OH 44195
Lab: (216)444-1164
*********************************************
Caminante, no hay camino.      Se hace camino al andar.

On Oct 12, 2007, at 4:49 PM, <Anne.Wilson@isrec.ch>
<Anne.Wilson@isrec.ch> wrote:

> Hi to all,
>
> It's interesting that this question has come up as we have some
> related problems with our data backup of files originating from
> DIVA. We have found that if you export as FCS files all the
> relevant info in the Exp name and file name goes with it
> (incidentally we use the same name for each in order to keep track
> of whose file it is and the date it was recorded). For eg. for my
> expts the name (both Expt and specimen) is AW121007 for today  -
> 12th October 2007 (AW is my initials). So each person uses the same
> system. If you export as FCS files all this follows and analysis in
> either FlowJo or CellQuest retains all this info. Some of the users
> follow this with details of the expts (mouse number, timepoint
> etc), others with just nos 1 to x......... depending on their
> needs. Incidentally we use the same system for files generated on
> other machines (as well as a Canto and an Aria, we currently have
> FACScans, FACSCaliburs and believe it or not a Cyan). However, we
> have major problems with automatic backup systems for files from
> the Canto and Aria (ie DIVA), - if we export as an 'Expt' all this
> info is lost, the files remain a data base number which does not
> identify the file name or even (worse) the date of acquisition,
> just the date of export. As we have around 35 users of the Canto
> alone, this means that all the files are lumped in together with no
> means of identifying what belongs to who other than rexporting into
> DIVA, and we only have this program on the cytometers themselves,
> all our researchers use FlowJo on a site license. It is only as FCS
> files that this information is retained.
> So my question is - why has no one (and where are the BD software
> engineers?) figured out a way to make this more user (and backup)
> friendly. Not everyone has the means or even desire to use DIVA as
> their major analysis program (as our BD technical engineer tried to
> convince me today). OUr FACS facility manager has tried in vain to
> get some answers from BD in vain, and our IT manager is tearing his
> hair out.....
>
> Any suggestions?
> And is there a BD software engineer listening out there ?
>
> Anne
>
> Dr Anne Wilson
> Ludwig Institute for Cancer Research
> Lausanne Branch
> University of Lausanne
> CH-1066 Epalinges
> Switzerland
>
> tel: + 41 21 692 5971
> fax: + 41 21 692 5995
> email: Anne.Wilson@isrec.ch
>
>  -----Original Message-----
> From: Adrian Smith [mailto:a.smith@centenary.usyd.edu.au]
> Sent: vendredi, 12. octobre 2007 01:24
> To: Cytometry Mailing List
> Subject: Re: Using DIVA Exp Files in Flojo
>
> On 11/10/2007, at 2:16 AM, Houston, Jim wrote:
>
>> We have been using the BD Diva Files for some time in FloJo.  I
>> now have another problem.
>>
>> I know that DIVA uses the Specimen name when exporting files as
>> FCS.  We usually use the same Exp name and Specimen to make things
>> less complicated.
>>
>> Now I have a set of experiments that we run with different
>> specimen names under 1 exp.    In FloJo you cannot seem to access
>> the Specimen name directly.    FloJo support was unable to help in
>> this also.  BD support is slow at best.
>>
>> If you have experience in this area please let me know some clues
>> on how to handle this.
>>
>> I have also notice using the DIVA software that when you change
>> some user keywords they do not export out.  Any idea with what is
>> up with that?
>
> Hi Jim,
>
> (this is my understanding of how it works - if anyone can add or
> change anything I would love to hear it!)
>
> Diva can export data in three different ways:-
>
> - FCS2 - I don't know what it does with keywords here as I never
> use it
> - FCS3 - FCS3 files are rewritten and renamed during the export
> procedure
> - Experiment - FCS files are moved out of the database along with
> an xml file.
>
> In both FCS3 and Experiment exports it looks like the specimen name
> is written to the "$SRC" keyword. You can use FlowJo preferences to
> use that as part of your workspace display name and/or you can add
> it is a column in the workspace display.
>
> In the case of an Experiment export you will certainly want to
> check the preferences for display name or you may end up displaying
> the filename which in this case is just a number (assigned by the
> Diva database). In an FCS3 export the filename is actually created
> from a concatenation of the Specimen and Tube names.
>
> When you are exporting as Experiment any changes in keywording made
> after the files are recorded do not show up in the FCS files
> themselves because the files are just moved, not rewritten. The
> changes are included in the accompanying xml files (which is not
> (currently?) much use in FlowJo).  If you export as FCS 3 the
> changes in keywords are included in the files as they are rewritten.
>
> Because of the keyword issue we have been exporting as FCS3 files
> but that creates two problems - (i) it is much slower and (ii) the
> filenames can end up longer than 28 character which can create
> problems keeping track of them in FlowJo (Mac) if you move them
> around after starting your analysis.
>
> What would be ideal would be an export mechanism that resulted in
> updated keywords in FCS files but also retained the xml (so Diva
> experiment specific information can be retained in case it needs to
> be reimported into Diva). Ideally this could be run as a batch job
> overnight in order to maximise analysis time during working hours.
> Anyone in the software group at BD listening :)
>
> Regards,
>
> Adrian Smith
> Centenary Institute, Sydney, Australia

Received on Tue Oct 16 14:58:00 2007
*    This message: [ Message body ]
*    Next message: Telford, William (NIH/NCI) [E]: "RE: red diode laser
on FACSVantage"
*    Previous message: Michie, John, Dr : "RE: Clinical Lab Med"
*    In reply to: Anne.Wilson@isrec.ch: "RE: Using DIVA Exp Files in
Flojo"
*    Next in thread: y.Isomoto: "Re: Using DIVA Exp Files in Flojo"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST
\*********************************************************************************************

Analyzing Diva Experiments using 3rd party software
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: Novo, David <david.novo@denovosoftware.com>
Date: Sun Oct 14 2007 - 13:28:39 EDT
Hello Anne,

I would suggest that a quicker alternative exists to waiting for BD to
change the export format feature in Diva. As far as I can tell, it is
not designed to share data among different software, but among
different
installations of Diva. And it does that just fine, but does not help
anyone not wishing to use Diva.

FCS Express users have had the ability to import Diva Experiments for
at
least 3 years, and we have kept up to date with all the new Diva
versions. You can import your plots, gates, compensation, text boxes,
stats windows, quads, markers, text boxes from the Diva worksheet and
an
identical analysis gets created within FCS Express.

Also, the problem you describe below is also accounted for and you can
actually choose what keyword(s) appear in the file dialog. Instead of
the non-informative numeric filename appearing, you can choose any
keyword (or combination) you want. For instance, the windows file
dialog
can display the TUBE NAME (which is what Diva displays in the tree),
instead of the filename.

Please see our web site for more information

http://www.denovosoftware.com/site/Diva.shtml

http://www.denovosoftware.com/site/FCS_FileDisplay.shtml

You should give it a try, at least to save your IT manager's remaining
hair :-)

-Dave

---------------------------------------------------------

David Novo

President

De Novo Software

Phone: (213) 384-7000

Fax: (310) 943-1489

________________________________

From: Anne.Wilson@isrec.ch [mailto:Anne.Wilson@isrec.ch]
Sent: Friday, October 12, 2007 1:50 PM
To: cyto-inbox
Subject: RE: Using DIVA Exp Files in Flojo

Hi to all,

It's interesting that this question has come up as we have some
related
problems with our data backup of files originating from DIVA. We have
found that if you export as FCS files all the relevant info in the Exp
name and file name goes with it (incidentally we use the same name for
each in order to keep track of whose file it is and the date it was
recorded). For eg. for my expts the name (both Expt and specimen) is
AW121007 for today  - 12th October 2007 (AW is my initials). So each
person uses the same system. If you export as FCS files all this
follows
and analysis in either FlowJo or CellQuest retains all this info. Some
of the users follow this with details of the expts (mouse number,
timepoint etc), others with just nos 1 to x......... depending on
their
needs. Incidentally we use the same system for files generated on
other
machines (as well as a Canto and an Aria, we currently have FACScans,
FACSCaliburs and believe it or not a Cyan). However, we have major
problems with automatic backup systems for files from the Canto and
Aria
(ie DIVA), - if we export as an 'Expt' all this info is lost, the
files
remain a data base number which does not identify the file name or
even
(worse) the date of acquisition, just the date of export. As we have
around 35 users of the Canto alone, this means that all the files are
lumped in together with no means of identifying what belongs to who
other than rexporting into DIVA, and we only have this program on the
cytometers themselves, all our researchers use FlowJo on a site
license.
It is only as FCS files that this information is retained.

So my question is - why has no one (and where are the BD software
engineers?) figured out a way to make this more user (and backup)
friendly. Not everyone has the means or even desire to use DIVA as
their
major analysis program (as our BD technical engineer tried to convince
me today). OUr FACS facility manager has tried in vain to get some
answers from BD in vain, and our IT manager is tearing his hair
out.....

Any suggestions?

And is there a BD software engineer listening out there ?

Anne

Dr Anne Wilson
Ludwig Institute for Cancer Research
Lausanne Branch
University of Lausanne
CH-1066 Epalinges
Switzerland

tel: + 41 21 692 5971
fax: + 41 21 692 5995
email: Anne.Wilson@isrec.ch
Received on Mon Oct 15 14:38:00 2007
*    This message: [ Message body ]
*    Next message: enrico lugli: "summary of replies on intracellular TGF-
beta and IL-10 detectionþ"
*    Previous message: Cyril Cohen: "Canto 2 vs. Cytomics FC500"
*    In reply to: Anne.Wilson@isrec.ch: "RE: Using DIVA Exp Files in
Flojo"
*    Next in thread: bunny: "Re: Using DIVA Exp Files in Flojo"
*    Contemporary messages sorted: [ By Date ] [ By Thread ] [ By
Subject ] [ By Author ] [ By messages with attachments ]
This archive was generated by hypermail 2.1.8 : Wed Jan 31 2007 -
03:12:00 EST

Re: Using DIVA Exp Files in Flojo
*    This message: [ Message body ] [ More options ]
*    Related messages: [ Next message ] [ Previous message ] [ In reply
to ] [ Next in thread ]
From: <sede0004@umn.edu>
Date: Tue Oct 16 2007 - 10:37:56 EDT
Hello All,

I would like to make one comment on exporting Diva experiments in hope
it
saves some headaches. You can greatly reduce time by exporting to the
desktop or drive. Most know this but I want to emphasize.

DO NOT EXPORT TO A THUMBDRIVE (USB MEMORY STICK)!

Diva hates this and it takes far too long. I have my users export to
desktop and then drag over to thumb drive. This procedure has helped
quite
a bit.

Regards,

--

Joel M. Sederstrom, M.B.S.
Director, Cytometry and Cell Sorting Core
Baylor College of Medicine
Phone: 713.798.3774
email: sederstr@bcm.edu

http://www.bcm.edu/flowcytometry/

On Oct 15 2007, Marty Bigos wrote:

>Not to be an apologist for BD (some at that company would
>be shocked if I said anything that could be construed as
>complimentary to the company, much less the DiVa
>software), but the Experiment export has a different
>function than FCS export.
>
>FCS export is suitable for analysis of data files by a 3rd
>party program. All the annotation information entered in
>the DiVa program is kept in the FCS file, including any
>compensation done in DiVa. It is up to the 3rd party
>supplier to know where all that info is and to use it
>properly.
>
>Experiment export is not useful for this. Not only are the
>file names useless, any changes to the annotation after
>data collection is not recorded in the FCS file. The
>Experiment export, however, is very useful for backup and
>archiving. All plots and gates on the worksheets are kept,
>providing documentation for sorting that may have been
>done. And this allows users to set up and annotate an
>experiment fully on stand-alone Diva software on a remote
>computer, export it as an experiment, and import it on the
>instrument connected system. This can help throughput in a
>busy facility.
>
>This system, however, could work better. Exporting
>experiments (or FCS files) is glacially slow, due to poor
>design of the DiVa software. However, don't expect this to
>be fixed in your lifetime.
>
>Marty
>Gladstone Flow Core
>
>On Fri, 12 Oct 2007 22:49:35 +0200
>  <Anne.Wilson@isrec.ch> wrote:
>> Hi to all,
>>
>> It's interesting that this question has c