<html>
<body>
Greetings All:<br><br>
An underlying assumption is that the computer clock is accurate.
Usually this is the case, and when it fails, it is because the mother
board watch battery has died while the computer was turned off (not an
experiment problem). Computers connected to the network check their
time via a time server, but this function only sets the time, it doesn't
log time errors. Hopefully any small time changes aren't going to
be a factor. <br><br>
NIST has <a href="http://www.nist.gov/pml/div688/grp40/its.cfm">time
servers</a> that can be polled. In principle the data collection
software could validate the elapsed time by this means. <br><br>
Is the current situation adequate, or do we need to use the time
servers? My feeling is we don't need the time servers, but I'll
throw out the idea for discussion.<br><br>
Glen<br>
Aviv Biomedical, Inc.<br><br>
<br><br>
At 10:59 AM 1/25/2013, Ghirlando, Rodolfo (NIH/NIDDK) [E] wrote:<br>
<blockquote type=cite class=cite cite="">Hi Borries -<br><br>
It would appear as though the values of w^2t in the file header correlate
with the adjacent time stamp in seconds. It could be that the time stamp
is obtained through w^2t.<br><br>
Whatever it is, these times (be they t or w^2t) eventually lag date and
time stamps on the XLA/I (as obtained from the cell log files) and
Windows OS on the PC.<br><br>
Thanks.<br><br>
Kind regards, Rodolfo<br><br>
<br><br>
-----Original Message-----<br>
From: Walter Stafford
[<a href="mailto:wstafford3@walterstafford.com" eudora="autourl">
mailto:wstafford3@walterstafford.com</a>]<br>
Sent: Friday, January 25, 2013 10:38 AM<br>
To: Borries Demeler<br>
Cc: Ghirlando, Rodolfo (NIH/NIDDK) [E]; 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 not been<br>
> investigated? I do not have this version to test myself, but such
errors would<br>
> propagate into some analysis methods in UltraScan as well. As far as
I know<br>
> the w^2t values are reported directly from the DA system of the XLA,
I am not<br>
> certain where the time values originate. The w^2t values *may* be
affected as well,<br>
> and that should be 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
(NIH/NIDDK) [E] wrote:<br>
>> Dear friends and colleagues,<br>
>><br>
>> 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).<br>
>><br>
>> 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.<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
14.0c, which you can download from
<a href="https://sedfitsedphat.nibib.nih.gov/software/Shared%20Documents/sedfit140c.zip" eudora="autourl">
https://sedfitsedphat.nibib.nih.gov/software/Shared%20Documents/sedfit140c.zip</a>
<br>
>><br>
>> 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.<br>
>><br>
>> 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!<br>
>><br>
>> 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.<br>
>><br>
>> We have discussed this matter with our Beckman service engineer
and it appears as though the company is now addressing this issue.<br>
>><br>
>> 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.<br>
>><br>
>> Please let me know if you have any questions, or if any problems
occur 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
Cellular Imaging and Macromolecular Biophysics National Institute of
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" eudora="autourl">
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" eudora="autourl">
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" eudora="autourl">
http://list.rasmb.org/listinfo.cgi/rasmb-rasmb.org</a></blockquote></body>
</html>