<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 9.00.8112.16457"></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT color=#0000ff size=2 face=Arial>Matt, these type of problems, and
things such as motion problems with the slit assembly, are exactly what the
absorbance log files <U>should</U> be able to help diagnose. But
the log files generated by the GUI do not record basic information such as
when each scan starts and stops, and hence they are <U>useless</U> to both
the users and service technicians. Making the log files useful should be a
trivial software change, and a number of us have asked for this for at least 10
years now, but nothing has ever been done.</FONT></P>
<DIV><FONT size=2><FONT color=#0000ff face=Arial>It is also long past time for
Beckman to clarify exactly what the two time stamps recorded in the headers
(and also the Windows file time stamp) mean. Are these the values when the
scan is first initiated (before the instrument goes to 6.5 cm to read the
intensities and set the PMT voltage and gain), or after that step occurs, or at
the end of the scan? Again software writers have asked for such clarifications
many times, but to my knowledge none of us have ever gotten an
answer.</FONT></DIV>
<P><FONT color=#0000ff face=Arial>John</FONT><BR><BR>-----Original
Message-----<BR>From: rasmb-bounces@list.rasmb.org [<A
href="mailto:rasmb-bounces@list.rasmb.org">mailto:rasmb-bounces@list.rasmb.org</A>]
On Behalf Of Rhyner, Matthew N<BR>Sent: Friday, January 25, 2013 10:48 AM<BR>To:
John Burgner; rasmb@list.rasmb.org<BR>Cc: 'Walter Stafford'<BR>Subject: Re:
[RASMB] Time-stamp checks for SV data<BR><BR>All-<BR><BR>Thank you for these
messages. We are aware of the issue and are actively investigating the
root cause.<BR><BR>Matthew N Rhyner, PhD<BR>Strategic Product Manager<BR>Beckman
Coulter, Inc.<BR>Mobile: 404-313-1811<BR><BR><BR>-----Original
Message-----<BR>From: rasmb-bounces@list.rasmb.org [<A
href="mailto:rasmb-bounces@list.rasmb.org">mailto:rasmb-bounces@list.rasmb.org</A>]
On Behalf Of John Burgner<BR>Sent: Friday, January 25, 2013 1:32 PM<BR>To:
rasmb@list.rasmb.org<BR>Cc: 'Walter Stafford'<BR>Subject: Re: [RASMB] Time-stamp
checks for SV data<BR><BR>Taking any large time interval from a series of scans
and calculating the w^2dt for that interval gives the same value calculated from
the w^2t values in the file header so yes both values are incorrect. Note
also that windows stores file creation times accurate to 1 sec.<BR>John
Burgner<BR><BR>-----Original Message-----<BR>From: rasmb-bounces@list.rasmb.org
[<A
href="mailto:rasmb-bounces@list.rasmb.org">mailto:rasmb-bounces@list.rasmb.org</A>]
On Behalf Of Walter Stafford<BR>Sent: Friday, January 25, 2013 10:38 AM<BR>To:
Borries Demeler<BR>Cc: rasmb@list.rasmb.org<BR>Subject: Re: [RASMB] Time-stamp
checks for SV
data<BR><BR>Borries,<BR><BR> The time
values in the file header are "elapsed time" from the the time the rotor starts
turning and should not be used in analysis in any case. SEDANAL uses
integral(w^2 dt), which is the correct value to use for all analyses.<BR><BR>So
your question is important: Are those values reported correctly or not in
version 6?<BR><BR>Walter<BR><BR>_________________________<BR>Walter
Stafford<BR>wstafford3@walterstafford.com<BR><BR><BR><BR>_________________________<BR>Walter
Stafford<BR>wstafford3@walterstafford.com<BR><BR><BR><BR>On Jan 25, 2013, at
10:13, Borries Demeler wrote:<BR><BR>> Rodolfo:<BR>><BR>> are w^2t
values reported in the file header not affected, or has that<BR>> not been
investigated? I do not have this version to test myself, but<BR>> such errors
would propagate into some analysis methods in UltraScan as<BR>> well. As far
as I know the w^2t values are reported directly from the<BR>> DA system of
the XLA, I am not certain where the time values<BR>> originate. The w^2t
values *may* be affected as well, and that should<BR>> be<BR>looked at by
someone with a Proteomelab ver.6.<BR>><BR>>
-borries<BR>><BR>><BR>> On Fri, Jan 25, 2013 at 09:29:39AM -0500,
Ghirlando, Rodolfo<BR>> (NIH/NIDDK)<BR>[E] wrote:<BR>>> Dear friends
and colleagues,<BR>>><BR>>> It has come to our (Joy Zhao, Peter
Schuck, Grzegorz Piszczek, Chad<BR>Brautigam and myself) attention that
sedimentation coefficients based on SV data collected using the ProteomeLab
XLA/I version 6 acquisition software are up to 10% larger than expected
(depending on the rotor speed).<BR>>><BR>>> We have traced this to a
smaller than expected elapsed time stamp in<BR>>> the<BR>file header. A
correction for this has been implemented in SEDFIT based in part on the Windows
OS file creation time stamp. This version has been released, as indicated in the
forwarded email from the SEDFIT-L list below, and we will report more details on
this shortly.<BR>>><BR>>> In addition Beckman Coulter has been
advised of this issue.<BR>>><BR>>>
Sincerely,<BR>>><BR>>> Rodolfo
Ghirlando<BR>>><BR>>><BR>>> FORWARDED
MESSAGE<BR>>><BR>>><BR>>> Dear
Colleagues,<BR>>><BR>>> This is to let you know of a critical SEDFIT
update with version<BR>>> 14.0c, which you can download from<BR>>>
<A
href="https://sedfitsedphat.nibib.nih.gov/software/Shared%20Documents/sedfi">https://sedfitsedphat.nibib.nih.gov/software/Shared%20Documents/sedfi</A><BR>>>
t140c.zip<BR>>><BR>>> It has a very important new feature for the
analysis of sedimentation<BR>velocity: it automatically compares the elapsed
times reported in the data file headers with the time differences obtained from
the file creation timestamps generated by the Windows operating system on the
PC.<BR>>><BR>>> Why would we need this? In the course of a joint
study between our<BR>>> lab<BR>and the labs of Rodolfo Ghirlando, Greg
Piszczek and Chad Brautigam, we have recently discovered that data files can
have elapsed time entries less than the differences from the operating system
timestamp, by as much as 10%.<BR>Obviously, if the elapsed time entry is 10% too
low then this leads to s-values that are 10% too high!<BR>>><BR>>>
We have double checked data from many different instruments, and<BR>correlated
this discrepancy in elapsed times with the ProteomeLab data acquisition software
version 6. No time differences, or only trivial ones, were observed for
instruments running earlier versions of the data acquisition software. In some
runs the overall difference amounts to hours at the end of the run, and I
believe that the operating system timestamp is correct. We will distribute more
detailed information shortly, but want to give you already a heads-up in the
meantime with this note: If you are running version 6 you may want to examine
the data files, and/or time the data acquisition process yourself, to
verify.<BR>>><BR>>> We have discussed this matter with our Beckman
service engineer and<BR>>> it<BR>appears as though the company is now
addressing this issue.<BR>>><BR>>> The new SEDFIT release can fix
this problem for the data analysis.<BR>>> First,<BR>it automatically
checks and creates a report if a systematic and significant discrepancy exists
between differences in the file time-stamp and differences in the header elapsed
time. If there appears to be a problem (i.e. apparent dilation factor greater
than a user-defined threshold, initially defaulted to 1.005 or 0.5%), SEDFIT
will create a report and then offer to write data files (under different names,
of course) with time entries based on a dilation factor extracted from the file
timestamps.<BR>Subsequent analysis of these time-corrected data files should
eliminate the problem, as it did perfectly for the data in our study. Such
time-corrected scan files should also be the ones loaded into SEDPHAT, which
will get its own update shortly.<BR>>><BR>>> Please let me know if
you have any questions, or if any problems<BR>>> occur<BR>with the new
version.<BR>>><BR>>> Best wishes and good luck,<BR>>>
Peter<BR>>><BR>>><BR>>> Peter Schuck, PhD<BR>>> Chief,
Dynamics of Macromolecular Assembly Section Laboratory of<BR>>> Cellular
Imaging and Macromolecular Biophysics National Institute of<BR>>>
Biomedical Imaging and Bioengineering, NIH<BR>>> 13 South
Drive<BR>>> Bldg 13, Rm 3N17<BR>>> Bethesda, MD 20892<BR>>>
phone: (301) 435-1950<BR>>> fax: (301) 480-1242<BR>>> email:
schuckp@mail.nih.gov<BR>>><BR>>><BR>><BR>>>
_______________________________________________<BR>>> RASMB mailing
list<BR>>> RASMB@list.rasmb.org<BR>>> <A
href="http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org">http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</A><BR>><BR>>
_______________________________________________<BR>> RASMB mailing
list<BR>> RASMB@list.rasmb.org<BR>> <A
href="http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org">http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</A><BR><BR>_______________________________________________<BR>RASMB
mailing list<BR>RASMB@list.rasmb.org<BR><A
href="http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org">http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</A><BR><BR>_______________________________________________<BR>RASMB
mailing list<BR>RASMB@list.rasmb.org<BR><A
href="http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org">http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</A><BR><BR><BR>Please
be advised that this email may contain confidential information. If you
are not the intended recipient, please notify us by email by replying to the
sender and delete this message. The sender disclaims that the content of
this email constitutes an offer to enter into, or the acceptance of, any
agreement; provided that the foregoing does not invalidate the binding effect of
any digital or other electronic reproduction of a manual signature that is
included in any
attachment.<BR><BR><BR>_______________________________________________<BR>RASMB
mailing list<BR>RASMB@list.rasmb.org<BR><A
href="http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org">http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</A><BR></P></FONT></BODY></HTML>