Posted by **Sébastien Morin** on January 08, 2009 - 05:40:

Hi, I thought about the task (Should I add the implementation of relaxation dispersion as a task on the Gna web site ?) and here is how I see the flow-through of an analysis... 1. A user will want to perform relaxation dispersion analysis. The user will first have to chose whether CPMG or R1rho experiments were recorded, the choice of which will determine if intensities are associated to different CPMG pulse train frequencies or to different R1rho spin lock field strength. Let's say the user types the command: relax_disp.exp_type('cpmg') and chooses the CPMG experiment. The intensities will then be associated to different CPMG pulse train frequencies, or to a null frequency (for the reference spectrum). We can now assume that the user recorded CPMG experiment from which R2eff values are extracted as follows: R2eff = ( 1 / T ) * Ln( Icpmg / Iref ) where T is the constant time relaxation delay, Icpmg is the peak height with CPMG, and Iref is the peak height without CPMG (reference). There should be a function to input the delay T used... Should this function be called something like: relax_disp.cpmg_delayT() and accept a float ? From this step, peak intensities will be used to calculate R2eff for the different frequencies used. How should duplicated reference spectra (if present) be treated (since they have an effect in every R2eff calculated) ? In the future, we could add a function for selecting this approach or another (if others exist and are of interest). 2. The user will then need to chose which mathematical model to use, fast or slow exchange. Let's say the user types a command like: relax_disp.select_model('fast') and chooses fast exchange. (Should this function be renamed to something like: relax_disp.cpmg_select_model() since it is associated to CPMG experiments ?) The R2eff values calculated in part 1 will then be input in the chosen equation and minimised. This is different as in standard curve fitting for R1 and R2, since the R2eff values are first calculated and then are passed to the dispersion equations to be minimised. Am I right ? In the case of CPMG data in the fast-exchange limit, should the relaxation dispersion specific user commands be as follows: relax_disp.exp_type('cpmg') relax_disp.cpmg_delayT(0.040) relax_disp.cpmg_select_model('fast') and should the data go as follows: intensities --> calculated [R2eff] --> minimised [R2, Rex, kex] ??? ====================================== ====================================== Moreover, what about the intermediate-exchange limit ? Is that of any importance and should it be implemented also in relax ? I propose yes, although I'll have to check for the equations, and everything... Also, as for choosing whether slow-, intermediate- or fast-exchange equations are best suited for the data, there is, of course, the use of model selection implemented into relax, but also the use of the alpha parameter (Millet et al., JACS, 2000, 122: 2867-2877 (equation 14)) which can help determining the exchange limit... How could we combine both ? Finally, what about group fitting of dispersion data to extract better parameters based on a common exchange rate (kex or kA, for fast- or slow-exchange, respectively) ? Should this be thought about in the beginning of the development or will it be easy to implement this when the rest works ? Ok, enough for now... Already a lot of work for tomorrow..! Regards, Séb :) Edward d'Auvergne wrote:

Hi, I'll comment on all your points below. On Tue, Jan 6, 2009 at 11:15 PM, Sébastien Morin <sebastien.morin.1@xxxxxxxxx> wrote:Hi Ed, I started a branch (relax_disp) for implementation of relaxation dispersion code. ============================================ The CPMG relaxation dispersion approach I presently work with is derived from pulse sequences developped in Lewis Kay's laboratory (Hansen, Vallurupalli & Kay, 2008, J.Phys.Chem.B 112: 5898-5904). The equation for R2eff is as follows : R2eff = ( 1 / T ) * Ln( Icpmg / Iref ) where T is the constant time relaxation, Icpmg is the peak height with CPMG, and Iref is the peak height without CPMG. Then, from these R2eff (recorded with varying CPMG frequency), one can fit relaxation dispersion and extract Rex, pa, pb, dw, tex, etc, depending on the exchange regime (slow or fast)... I wrote an interactive Mathematica notebook concerning the basics of CPMG relaxation dispersion... You can find it at : http://maple.rsvs.ulaval.ca/mediawiki/index.php/Relaxation_dispersion ============================================I've checked out the branch to watch the changes and downloaded the Mathematica notebook. This notebook seems quite useful to get an idea of what happens to the relaxation dispersion profiles.A few questions come to my mind, at this point. How do we want to treat relaxation dispersion within relax ? Do we want to support both CPMG and R1rho relaxation dispersion approaches ? -> I propose starting with CPMG.I would suggest that too, but relax should be designed to handle both from the start. Maybe a user function such as relax_disp.exp_type() could be used to specify which was collected. If this is done then, once relax is running with the CPMG data, adding support for R1rho may only take one or two days of work adding a few additional functions to the maths_fns code. This will be very trivial and could be added by anyone else interested in collecting this type of data.Do we want the code to work with peak heights or with calculated R2eff ? -> I propose starting with R2eff.Here I suggest peak heights as this code already exists. Hence calculating R2eff can be one part of the minimisation function. Or maybe even calculate these as the first part of the specific_fns.relax_disp.Relax_disp.minimise() function prior to running the mathematical optimisation. relax now has all the infrastructure for peak heights, and therefore doing it this way makes it significantly easier for the user while not being too much for the implementor (a single small function will be sufficient). In the future, R2eff may be input instead and this part skipped. Maybe with the user function relax_disp.r2eff_read().Do we want to handle both slow- and fast-exchange ? -> I propose implementing both...I think we should have everything (but not all done at once or all by you). First though, the simple fast-exchange formula. But then possibly all the formula in your Mathematica notebook. These formula are in reality mathematical models. Therefore they should be specified using a user function relax_disp.select_model() mimiking model_free.select_model(). With this user function, each model/equation can be implemented one by one after relax can already successfully perform a relaxation dispersion analysis.Do we want to support the use of multiple field data simultaneously ? -> I propose yes, otherwise users will use some other in-house programs which allow it...Is multiple field strength data not essential for relaxation dispersion? The frq.set() user function I recently added to relax can be used to specify which spectrometer frequency the peak intensities come from.Do we want the code to be able to choose between slow- and fast-exchange automatically, using some model selection criteria ? -> I propose yes, otherwise users will use some other in-house programs which allow it...This is statistical model selection which relax already implements. I have no idea which model selection technique will be best, but I would guess AIC or BIC model selection will do a decent job. Currently (well, I haven't followed the relaxation dispersion literature too closely) the way the model is selected is by using F-tests. However this is statistically flawed and should never, ever be done. Statisticions would cringe if they saw what we in the NMR field do here. You just have to read the fine print on F-test to see why - F-tests are only for testing the significance of models which are "parametric restrictions" of each other! That is definitely not the case here!!! Oh, the second problem is that hypothesis testing for model selection was abandoned by this field in the 40's with only likelihood ratio tests remaining today. The reason is that you can manipulate your tests to get the result you want - as has been done in quite a number of model-free papers! For implementing this - at the end - just run the model_selection() user function and see which methods are missing from the specific_fns code. Only a few basic methods are required which have nothing to do with model selection itself.Let me know if you have a few ideas...I have a few other small ideas, but I'll save these until later. Cheers, EdwardRegards, Séb :) Edward d'Auvergne wrote:Hi, If you would like to implement this, please feel free. I have so much to do currently with relax that I won't have a chance to develop this code for a long time. This development will have to be done within a branch because of the disruptive nature of the code. I would suggest that you do something similar to what you did with the consistency testing code, by copying and modifying the reduced spectral density mapping code. However in this case, I would suggest copying and modifying the relaxation curve-fitting code. Don't be afraid of doing anything, as I'll check all committed code as always and every change can always be reverted. For a start, I would develop a system test. Having some limited relaxation dispersion data, as peak heights, and the final results will be required. Published data could be useful for this, as then it could be checked against the published results to make sure that the code is correct. Then you can store the input data into 'test_suite/shared_data', write a script called something like 'test_suite/system_tests/scripts/relaxation_dispersion.py' which implements a complete relaxation dispersion analysis (the script can be later copied into 'sample_scripts/'), and then have code in the system test checking if the final values are correct. Then I would implement the necessary user functions. Then the specific_fns code. And finally the maths_fns code with the relaxation dispersion equations. Finally debug until the system test passes. This is the order that I develop the analyses in relax, and is the best way to do this. At all points you can copy and modify the relaxation curve-fitting code as the concepts are quite similar. So similar in fact that implementing this analysis will not be too hard. It might be nice if you had a protein system to run this on in the end so you can publish the fact that you have implemented this code in relax. Well, assuming you decide to write this code. Regards, Edward On Tue, Dec 23, 2008 at 5:40 PM, Sébastien Morin <sebastien.morin.1@xxxxxxxxx> wrote:Hi, I have seen pass by the new pipe type 'relax_disp' a few weeks ago... Since relaxation dispersion is in the list of techniques planned to be supported in the future, I guess this is the first step toward implementation... I would like to contribute to the development of this type of analysis. What first steps could I do ? Should there be a new branch created to start this ? Should some unit and system tests be written ? Should first equations be introduced ? Let me know what are your plans for this, Ed, and I'll try to help you in any way you find useful. Regards, Séb :) _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list relax-devel@xxxxxxx To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel

Powered by MHonArc, Updated Thu Jan 08 10:40:36 2009