<HTML>
<HEAD>
<TITLE>Re: [RASMB] precision limit in quantifying protein aggregates by sedimentation velocity with Sedfit</TITLE>
</HEAD>
<BODY>
<BLOCKQUOTE><FONT COLOR="#800000"><I>Apologies for the apparent assumption in my recent mail that there is only one Arthur in the world!<BR>
</I><BR>
<BR>
Hi Yi-Ming and everyone<BR>
<BR>
We do very large numbers of such analyses - i.e. defining how much aggregate is present in a product. Generally we use the least-squares g(s) profile, fitting multiple guassians (1 for each species), and following a standard operating procedure to eliminate (as far as possible) subjectivity in choice of resolution and other parameters. We use this approach rather than c(s), as whilst with 'big monomers' the results will be identical, with lower s species (I note that your monomer is only 6.4S) one can 'lose' some of the n-mers in c(s) profiles. It is also easy, fitting g(s) profiles, to constrain your fit within sensible bounds for each n-mer species. Which is a fair thing to do, if you know that only one monomer species is present.<BR>
<BR>
That being said, however, Hans-Joachim has a good point to make. Your 2 cells show the estimate for the amount of monomer to be 98 ± 1%. I doubt that you can better that by much, however you do it! And your estimates for the s values of dimer, trimer & tetramer seem pretty good to me, given that only tiny amounts are present. OK, on a good day, we expect to find the g(s) profiles from 2 identically filled cells to be a little closer to each other than your c(s) data might suggest. At the end of the day, it comes down to whether you are doing an absolute estimate of amounts of n-mer, where quality is all and time of little importance. Or whether what counts is getting an answer to the question "how much aggregated?" to within a single percentage point. Which you have achieved.<BR>
<BR>
It's all a very big issue for the bio-pharma industry, of course.<BR>
<BR>
Kind regards<BR>
<BR>
Arthur<BR>
</FONT><BR>
<FONT COLOR="#800000"><BR>
</FONT></BLOCKQUOTE><FONT COLOR="#800000">--<BR>
*******************************************************<BR>
Arthur J Rowe<BR>
Professor of Biomolecular Technology<BR>
NCMH Business Centre<BR>
University of Nottingham<BR>
School of Biosciences<BR>
Sutton Bonington<BR>
Leicestershire LE12 5RD UK<BR>
<BR>
Tel: +44 (0)115 951 6156<BR>
+44 (0)116 271 4502<BR>
Fax: +44 (0)115 951 6157<BR>
email: arthur.rowe@nottingham.ac.uk<BR>
Web: www.nottingham.ac.uk/ncmh/business<BR>
*******************************************************<BR>
</FONT><BR>
<TT><BR>
</TT><BLOCKQUOTE><TT><BR>
Hi! Everyone:<BR>
We routinely use Sedfit to analyze sedimentation velocity data to detect<BR>
the aggregates in our protein products. Many of our results are consistent<BR>
with the size-exclusion HPLC regarding the percentages of the aggregates in<BR>
protein products. But we also found that sometimes the repeatability of<BR>
sedimentation velocity analysis is not very good. For example, in order to<BR>
test the repeatability of the method, we loaded the same sample (a<BR>
monoclonal antibody) to two different cells and make a sedimentation<BR>
velocity run. Then we analyzed the data from the two different cells using<BR>
sedfit to get C(S) profiles. From the C(S) profiles we calculated the<BR>
percentage of the species. We got the following results:<BR>
<BR>
Cell 1:<BR>
99.07% @ 6.4 s<BR>
0.74% @ 9.7 s<BR>
0.1% @ 11.3 s<BR>
0.08% @ 16.9 s<BR>
rmsd: 0.003517<BR>
<BR>
Cell 2:<BR>
97% @ 6.4 s<BR>
1.43% @ 8.9 s<BR>
0.42% @ 10.9 s<BR>
0.27% @ 13.6<BR>
0.15% @ 18.2<BR>
rmsd: 0.003533<BR>
<BR>
According to Dr. John Philo, sedimentation velocity is an excellent method<BR>
to detect and quantify the aggregate in protein products. Therefore I think<BR>
that the variations here are beyond the range we expect. Moreover, the<BR>
sedimentation coefficient of the dimmer and other oligomers are quite<BR>
different. Could anyone tell me, based on your experience and knowledge,<BR>
the precision limit of the software for quantitative determination of the<BR>
percentage of protein aggregate in a non-interactive system? If the<BR>
precision limit of the software is not a problem, what are the possible<BR>
sources for such large variations? Is it possible that the variations came<BR>
from the instrument or centerpieces?<BR>
<BR>
Thanks!<BR>
<BR>
Yi-Ming<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
RASMB mailing list<BR>
RASMB@rasmb-email.bbri.org<BR>
http://rasmb-email.bbri.org/mailman/listinfo/rasmb<BR>
</TT></BLOCKQUOTE><TT><BR>
</TT>
</BODY>
<br/>
<p>
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
</p>
</HTML>