Hi Andy,
For public mailing lists, it is best to avoid attaching files. This
puts a lot of strain on the open source infrastructure as the
attachment is copied many times and stored in many places on the
internet (there are 4 permanent archives of each relax mailing list,
see http://www.nmr-relax.com/communication.html). It is better to
attach files to a support request or task
(https://gna.org/support/?3154 and https://gna.org/support/?3155, for
example). As the message is getting quite long, I'll answer it in a
number of parts:
Do you have code for this R1rho model? It may help to have the code,
either to use it directly or for comparison and test suite purposes.
In relax, the implementation is in Python.
Here some very unoptimised code. Note that you have to adjust the offset
(see below).
J. Biol. NMR (2013), 55:211-218.
Cheers! This will come in handy for implementing the model.
In the paper is a formula that predicts accurately when it will work and
when it will not (Page 214, 4 lines from the bottom). This formula will
break when the relevant eigenvalue is no longer the smallest. As ever, this
treatment proves that the R1rho is resilient to differences in relaxation,
but to analyse data, use at minimum the 6x6 matrix.
The aim for relax is to support absolutely everything. It is up to
the user to judge the models, theory level, etc. If they use the
defaults, then they shouldn't go wrong.
But as numpy is used, the
different between Python and C is minimal. The fine details of the
implementation itself make more of a difference for speed than the
choice of language.
Debatable. Sure a decent workup in numpy gets you much faster, but you'll
notice even the ardent supports of numpy concede that C whoops it's ass. Ie
optimised numpy will be slower than C. I say that as someone that does
almost everything in python.
Well, FORTRAN beats C hands down, especially when you use BLAS and
LAPACK libraries. But I've see so many inefficient implementations in
my time - mostly replicating calculations at the lowest loop levels,
or preforming calculations in low loop level when it can be performed
higher up - that the implementation differences really are greater
than the language choice. I can even see this in the code for Dmitry
Korzhnev's cpmg_fit software (the clc_jac() function of the min_cp.c
file has quite a number of replicated calculations). But it is true
that fully optimised code would be fastest in the order of FORTRAN, C,
and finally Python. Though I doubt that fully optimised code exists
anywhere in the dispersion field, relax included ;)
Regards,
Edward
Re: [sr #3155] An R1rho expression for a spin in chemical exchange between two sites with unequal transverse relaxation rates