Hi all,
Thanks to Karl Koshlap, Richard Shoemaker, Andrew Fowler, Eugenio
Alvarado, Emeric Wasielewski and Craig Butts for their points of view
about the incorect calculation time experiment with the "time" and
"exptime" commands.
In a nutshell, the problem is mainly observed when / with:
a) experiments that have lots of loops such as 15N T2 measurements, arrays.
b) steady-state pulses are involved (positive or worse negative).
c) using long mixing times.
d) using "pad".
e) when doing very fast pulsing.
Curiously, time remaining displayed in the status at the bottom of the
main VnmrJ window (or the acqi window pre-VJ) is generally much closer
to reality, this means that this last result is not obtained from
command exptime or time !!! This will be already an improvement if we
could have access to the command or macro giving this result, not
perfect but better that with time and exptime command !
Finally, I am stupefied to understand that this problem is existing
from Vnmr 6.1C and is still observed with VnmrJ 3.2 system. These bugs
have been reported for years, and Varian never considered them to be
important, or possible never considered them to be bugs. I will fill a
new bug report, may be one day it will be considered as a real bug !
Unfortunately, we have written a nice macro that gives to users, just by
clicking on a buton, the date and time of the end of the experiments ...
This can be very comfortable when many experiments are submited .... But
this macro is never used, because it is based on the exptime command and
then gives wrong results :-( Users continues to evaluate by hand the
end of their experiences ... If one day a command giving a good
evaluation of the experiment time is discovered :-) I promise to share
this macro!
All the best !
Eric.
--------------------------------------------------------------------------------------------------------------------------------------
Yes, we have observed this, and believe it is related to
experiments that have some sort of a loop
or array, as in a pseudo-3D.
--------------------------------------------------------------------------------------------------------------------------------------
There have always been problems with VNMR/VNMRj calculating experiment
time, and these have been known and reported by many for years. There
are a number of ways this can happen, including (but not limited to):
1) It doesn't calculate the time accurately when steady-state
pulses are involved. If "ss" is a positive number, then the error is
usually negligible; however, if you use a negative number (i.e. ss=-4),
which is not uncommon for arrayed experiments depending critically on
intensity (i.e. DOSY or some relaxation experiments)... then it can be a
huge error (in some cases off by a factor of two). In this case the
time reported by the "time" command, vs. the displayed time in the
acquisition status window will both be incorrect.
2) Experiments with long mixing times are sometimes off (depends on
the experiment being used). I've noticed with many NOE experiments, the
discrepancy in the calculated time gets worse with longer mixing time.
I've never spent the time and effort to try to quantitate or isolate the
actual source of the problem.
3) IF you use "pad" (pre-acquisition delay), for example in
kinetics runs, the time given by the "time" command is total nonsense,
but you will see something close to the correct time in the acquisition
status display after "go". Apparently, the "pad" delay isn't used
properly at all for the "time" command, but the estimated time of
completion does take pad into account.
Sadly, most of the underlying code in VNMRj (much of it anyway) is
exactly the same as that found in VNMR 6.1C from the old days. These
bugs have been reported for years, and Varian never considered them to
be important, or possible never considered them to be bugs. I believe
that one might be able to edit the parameters used for the time
calculation by editing the parameter tables "paramvi", or by defining
things a certain way in the pulse sequence itself. You might well
receive a response from someone who has actually figured this out (maybe
somebody from Agilent). If so, it would be good information to share
with the group.
For me (and many others) I have lived with this issue, and found ways to
work around the problem (i.e. I can calculate the actual time of a DOSY
with ss=-4 and nt=16 pretty accurately just from experience, as can I
calculate exactly the time when using a "pad" array). I've always just
told my users that the result of the "time" command is somewhat like
what we get from the weather forecasters... it might be close, but it
might be totally wrong.
I'm not sure this helps, but you're not the first person to be
frustrated by this.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Just some observations over the past 14-15 years using Varian
instruments. I'll confirm what you see in general. The "time" macro
tends to get things wrong fairly often -- it doesn't seem to account
well for how things get incremented. This is still true today and if
anything used to be somewhat worse. Usually it's only by a small amount,
but for experiments with lots of loops such as 15N T2 measurements I've
seen it so far off that I wondered if I did something wrong (for example
1800 hours instead of 36 hours).
In my experience, the time remaining displayed in the status at the
bottom of the main VnmrJ window (or the acqi window pre-VJ) is generally
much closer to reality. It's still not great, but tends to be within a
few percent. I find this value underestimates for short experiments
(<5-10 minutes) but overestimates for longer experiments. I find it to
usually be within 5-10 minutes for medium long experiments (hours). I've
seen it off by 1.5-2 hours, but usually only for experiments several
days in duration.
As a rule, I usually have some idea how long an experiment will take,
and if typing "time" is far off from this, I'll manually estimate. It
certainly should be fixed, but is mostly a minor annoyance for me.
Before filing a bug report, you might want to check the bug lists and
archives on Agilent's website.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
I have noticed the time is miscalculated when doing very fast pulsing.
For example for 1D spectra of some fast-relaxing nuclei you can use
d1=0.010 and at=0.050.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
As an Agilent user, I observed the same problem too. I mainly noticed it
with T1 and T2 experiments. But I am still not able to well define where
is the bug. I just noticed it is a long time dating problem, as I can
see it on our recent VnmrJ 3.2 system and our antic Vnmr 6.2 system.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Yes, we see similar things but have not taken the time to systematically
work out when it occurs (we KNOW that the 1D-NOESY is wrong.... usually
underestimates time by around 10-15%. It also ignores the ZQF period in
working out the mixing time I believe).
Definitely report it (they LIKE bug reports, so don't be shy!).
Give as much detail as possible e.g. which sequence, how wrong it was.
And ideally keep copies of the experiments that went wrong so you can
send them parameter files etc.....
--
Eric Condamine <http://fr.linkedin.com/pub/eric-condamine/27/529/290>
Laboratoire de Resonance Magnetique Nucleaire
Institut de Biologie Structurale "Jean-Pierre Ebel"
UMR 5075 CNRS/CEA/UJF
41 rue Jules Horowitz
38027 Grenoble Cedex 01
***NEW ONE !*** Tel: (00 33) 4 38 78 38 89 ***NEW ONE !***
Fax: (00 33) 4 38 78 54 94
E.mail: eric.condamine_at_ibs.fr
Received on Sun Oct 07 2012 - 23:14:38 MST