Hi Troels, I'm still not sure why the TSMFK01 model results do not match what you expect (http://thread.gmane.org/gmane.science.nmr.relax.scm/18555/focus=4531). The code is very clean and there is nothing obvious. The problems I saw before with the k_AB parameter, you have now fixed. So I really don't know what is happening. I would recommend looking at a spin system with data at two fields, just in case the model is not stable for single field strength data. In any case, more testing of data is required to work out what is happening. If the motional parameters are truly within the range of the TSMFK01 model, then comparison to the numeric model should produce similar parameter values. This is also a useful sanity check. Maybe you could write an email to Martin Tollinger about getting some of the data used in the paper. This would include peak heights (or R2eff) as well as the optimised parameter values. Having both is important. Some of his code is in relax, so he is aware of the dispersion branch. If you explain what you would like to do and how you're in the process of implementing / debugging his model in relax, I'm sure he'd be happy to help. He may even still have the synthetic data he used in his paper (http://dx.doi.org/10.1021/ja011300z) - that would be the best for the checks. On the subject of the subject line, I have a few points about the lib.dispersion.tsmfk01 code to speed things up: 1) The dw * tau_CP mathematical operation occurs twice - this is a waste and the result can be stored as a variable and reused. An easy solution would be to put the denominator calculation before the numerator, and the rest should be obvious. 2) The tau_CP value is re-calculated each time. These values could be stored in data structure which is set up when the target function class is initialised (in the __init__() method). That way this calculation is avoided in the target function where it is much more computationally expensive. 3) Also related to point 2), Python has to convert your integer '2' into a float prior to the multiplication. If you use '2.0' instead, then that avoids the time required for Python type conversions. Implementing these drop the number of mathematical operations per loop per function call from 9 to 6, and removes a type conversion. So you should get a good speed up. Regards, Edward P. S. Be careful with the tau_CP to nu_CPMG calculation. In relax, the factor of 1/2 rather than 1/4 is often used. This is the notation used by CPMGFit. Different groups define nu_CPMG differently!