Hi Ed,
Please see the comments below...
Edward d'Auvergne wrote:
Hi,
Sorry for the delayed response, the last few months for me have been
crazy. Please see below for more:
On Tue, Jun 2, 2009 at 8:36 PM, Sébastien
Morin<sebastien.morin.1@xxxxxxxxx> wrote:
Hi,
This is a fairly old post, but I finally had time to think about these
issues... Please see below...
Edward d'Auvergne wrote:
Hi,
Is the frequency for the reference spectrum necessary? Isn't
cmpg_delayT set to zero in this case, i.e. the CPMG block is missing?
If it is necessary though, a value of None is probably a better choice
to identify it rather than the frequency of zero Hz.
I guess recording a reference for each frequency is necessary since the
intensity is to be extracted and could vary when changing magnet (along
with
S/N)...
I agree for a value of None for the reference spectrum (which is what is
presently in the code).
Ok, so we need a reference frequency set, but cmpg_delayT set to None.
Fine.
Another question I have is should the nu_cmpg value be given (with Hz
units), or would it be better if the omega_cmpg value was given (with
rad/s units)? If nu_cmpg is given, this will have to be converted
later to omega. I think we should have an explanation of both, after
the relevant model equations. Also the 'frq' arg of
relax_disp.cpmg_frq() might be better named as nu_cmpg or omega_cmpg
for clarity if this is frequency or angular frequency.
For this part, I am not sure about the units to use... 'cpmg_frq' needs to
be of the same units as 'kex' and 'dw' (see equations below). I guess 'kex'
and 'dw' should be in rad/s, so 'cpmg_frq' should also be in rad/s...
Is it right ?
Depending on the answer, 'cpmg_frq' will be renamed (to either 'cpmg_nu' or
'cpmg_omega').
I think we should use omega units (with the hidden radian unit). Do
you know what is normally used?
In the CPMGFit program by Art Palmer, the units seem to be seconds for
both the tcp (with tcp = 1 / 4 cpmg_frq) and Tau (with Tau = 1 / kex)
variables. Accordingly, if using the same approach, the units would be
1/s for both kex and cpmg_frq.
Hence, I still hesitate.
On one hand, the units should maybe be 1/s so the rates extracted with
our approach are the same as obtained using CPMGFit.
On the other hand, the units for kex and cpmg_frq should maybe be rad/s
since they need to be the same as for dw (Hz), the chemical shift
difference between the two states.
I am still confused as you may see...
--------------------------
FAST EXCHANGE
/ / kex \ 4 * cpmg_frq \
R2eff = R2 + Rex * | 1 - 2 * Tanh | ------------------ | * ------------- |
\ \ 2 * 4 * cpmg_frq / kex /
SLOW EXCHANGE
/ / dw \ 4 * cpmg_frq \
R2eff = R2A + kA - | Sin | -------------- | * ------------- |
\ \ 4 * cpmg_frq / dw /
where cpmg_frq = 1 / ( 4 * cpmg_tau ).
Also note that
we have to convert the cmpg_delayT value too. Unit analysis of the
equation
R2eff = ( 1 / T ) * Ln( Icpmg / Iref )
shows this. R2 is in units of rad/s. T is input in seconds. 1/T is
frequency in nu units of Hz. Therefore we need to convert to the
radian units of angular frequency by multiplying by 2pi as 2pi/T is in
rad/s units. The natural logarithm of peak intensities is unitless
and dimensionless.
I just had a look at the reference dataset included in the test suite (from
Hansen et al., J. Phys. Chem., 2008)...
When treating the delay T as is (in seconds), I get the same values for
R2eff as published in the paper (for the FF domain). However, if
multiplying
the delay T by 2pi, I get values for R2eff that a way too big.
delay T is in the pulse sequence and should be in seconds.
Fine.
I do not want to say that the logic behind unit analysis is deficient. I
agree with that logic, but I also think that, in this case, the delay T
should stay in seconds in order to get R2eff values of the good size...
Despite delay T being in seconds, R2eff is in rad/s. This is the same
as standard R1 or R2 where the time period in the pulse sequence is in
seconds whereas the fitted rate is in rad/s.
Fine.
What do you think ?
As long as a number of published results can be replicated, we should be
fine.
I agree.
Regards,
Séb
Regards,
Edward
--
Sébastien Morin
PhD Student
S. Gagné NMR Laboratory
Université Laval & PROTEO
Québec, Canada
Re: r8343 - in /branches/relax_disp: prompt/relax_disp.py specific_fns/relax_disp.py