[RASMB] Time-stamp checks for SV data

Fri Jan 25 11:31:01 PST 2013

Matt, these type of problems, and things such as motion problems with the
slit assembly, are exactly what the absorbance log files should 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
useless 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.

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.

John

-----Original Message-----
From: rasmb-bounces at list.rasmb.org [mailto:rasmb-bounces at list.rasmb.org] On
Behalf Of Rhyner, Matthew N
Sent: Friday, January 25, 2013 10:48 AM
To: John Burgner; rasmb at list.rasmb.org
Cc: 'Walter Stafford'
Subject: Re: [RASMB] Time-stamp checks for SV data

All-

Thank you for these messages.  We are aware of the issue and are actively
investigating the root cause.

Matthew N Rhyner, PhD
Strategic Product Manager
Beckman Coulter, Inc.
Mobile: 404-313-1811

-----Original Message-----
From: rasmb-bounces at list.rasmb.org [mailto:rasmb-bounces at list.rasmb.org] On
Behalf Of John Burgner
Sent: Friday, January 25, 2013 1:32 PM
To: rasmb at list.rasmb.org
Cc: 'Walter Stafford'
Subject: Re: [RASMB] Time-stamp checks for SV data

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.
John Burgner

-----Original Message-----
From: rasmb-bounces at list.rasmb.org [mailto:rasmb-bounces at list.rasmb.org] On
Behalf Of Walter Stafford
Sent: Friday, January 25, 2013 10:38 AM
To: Borries Demeler
Cc: rasmb at list.rasmb.org
Subject: Re: [RASMB] Time-stamp checks for SV data

Borries,

        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.

So your question is important: Are those values reported correctly or not in
version 6?

Walter

_________________________
Walter Stafford
wstafford3 at walterstafford.com

_________________________
Walter Stafford
wstafford3 at walterstafford.com

On Jan 25, 2013, at 10:13, Borries Demeler wrote:

> Rodolfo:
>
> are w^2t values reported in the file header not affected, or has that
> not been investigated? I do not have this version to test myself, but
> such errors would propagate into some analysis methods in UltraScan as
> well. As far as I know the w^2t values are reported directly from the
> DA system of the XLA, I am not certain where the time values
> originate. The w^2t values *may* be affected as well, and that should
> be
looked at by someone with a Proteomelab ver.6.
>
> -borries
>
>
> On Fri, Jan 25, 2013 at 09:29:39AM -0500, Ghirlando, Rodolfo
> (NIH/NIDDK)
[E] wrote:
>> Dear friends and colleagues,
>>
>> It has come to our (Joy Zhao, Peter Schuck, Grzegorz Piszczek, Chad
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).
>>
>> We have traced this to a smaller than expected elapsed time stamp in
>> the
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.
>>
>> In addition Beckman Coulter has been advised of this issue.
>>
>> Sincerely,
>>
>> Rodolfo Ghirlando
>>
>>
>> FORWARDED MESSAGE
>>
>>
>> Dear Colleagues,
>>
>> This is to let you know of a critical SEDFIT update with version
>> 14.0c, which you can download from
>> https://sedfitsedphat.nibib.nih.gov/software/Shared%20Documents/sedfi
>> t140c.zip
>>
>> It has a very important new feature for the analysis of sedimentation
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.
>>
>> Why would we need this? In the course of a joint study between our
>> lab
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%.
Obviously, if the elapsed time entry is 10% too low then this leads to
s-values that are 10% too high!
>>
>> We have double checked data from many different instruments, and
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.
>>
>> We have discussed this matter with our Beckman service engineer and
>> it
appears as though the company is now addressing this issue.
>>
>> The new SEDFIT release can fix this problem for the data analysis.
>> First,
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.
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.
>>
>> Please let me know if you have any questions, or if any problems
>> occur
with the new version.
>>
>> Best wishes and good luck,
>> Peter
>>
>>
>> Peter Schuck, PhD
>> Chief, Dynamics of Macromolecular Assembly Section Laboratory of
>> Cellular Imaging and Macromolecular Biophysics National Institute of
>> Biomedical Imaging and Bioengineering, NIH
>> 13 South Drive
>> Bldg 13, Rm 3N17
>> Bethesda, MD 20892
>> phone: (301) 435-1950
>> fax: (301) 480-1242
>> email: schuckp at mail.nih.gov
>>
>>
>
>> _______________________________________________
>> RASMB mailing list
>> RASMB at list.rasmb.org
>> http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org
>
> _______________________________________________
> RASMB mailing list
> RASMB at list.rasmb.org
> http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org

_______________________________________________
RASMB mailing list
RASMB at list.rasmb.org
http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org

_______________________________________________
RASMB mailing list
RASMB at list.rasmb.org
http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org

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.

_______________________________________________
RASMB mailing list
RASMB at list.rasmb.org
http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.rasmb.org/pipermail/rasmb-rasmb.org/attachments/20130125/3eb151b9/attachment.htm>