Hi, The infrastructure part for supporting multiple experiment types is now complete (section 2 of the post at http://thread.gmane.org/gmane.science.nmr.relax.devel/4530). This involves associating each spectrum ID string, by which the loaded peak intensities are identified, with an experiment type. All parts of relax - the user functions, prompt UI, script UI, GUI, sample scripts, test suite, and manual - have been updated to handle this. The implementation is exactly as I detailed in that post. It took a bit longer than I hoped, but now everything works smoothly.
In addition to this change, I have taken the opportunity to simplify the interface for the user. Instead of selecting one of 'cpmg fixed', 'cpmg exponential', 'r1rho fixed', 'r1rho exponential', the 'fixed' or 'exponential' part is now determined automatically. This is easy to do - if all relaxation time periods for all data (in one experiment set) are the same, then relax assumes the fixed time experiment. Otherwise an exponential data set is assumed. So now the user simply selects 'CPMG' or 'R1rho'. This will make it much easier to add 'MQ CPMG', 'MQ R1rho', 'ZQ CPMG', 'ZQ R1rho', 'DQ CPMG', 'DQ R1rho', 'EXSY', 'H/D exchange', etc. later on. Regards, Edward On 4 September 2013 20:30, Paul Schanda <[email protected]> wrote: > Hi Edward, > > I managed to find some literature data that are probably suitable. I will > get them from the authors in a week or so. > So that probably solves point 3). > > I agree that the infrastructure needs to be revised for MQ data. This might > in fact be the opportunity to re-think the structure. One might want to > jointly fit all kinds of data, e.g. SQ+MQ, or CPMG+R1rho. You should also > think of the possibility of adding in the future EXSY data. In the slow to > intermediate exchange, one might have EXSY + CPMG to be fit together. > If relax would be designed now in a way that is sufficiently flexible to > handle all this, it would be great. > > We will have a look at the code that Mathilde and Dominique have > implemented; this might also take a few days. > > best - > > > Paul > > > On 04.09.13 16:47, Edward d'Auvergne wrote: >> >> The following are reference development notes for how to modify relax >> to handle multi-quantum (MQ) data. Currently relax supports >> single-quantum (SQ) data but not MQ data. There are three aspects to >> this problem, detailed below. Note that the changes for part 2) will >> likely break the code of the relax_disp branch for a short time. >> >> >> 1) The MQ models. >> >> Firstly the specific MQ model(s) must be added to relax (following the >> steps at >> http://wiki.nmr-relax.com/Tutorial_for_adding_relaxation_dispersion_models_to_relax). >> This part is relatively trivial, especially if the code already >> exists, a published reference exists, and equations can be copied from >> a paper directly into the relax manual. For example the 'MQ CR72' >> model supported by GUARDD (http://dx.doi.org/10.1021/ja049968b). >> >> >> 2) Infrastructure changes. >> >> There is one infrastructure change required to support this. The >> reason is because most people with MQ data will want to analyse it >> simultaneously with SQ data (well, that is my guess from the >> literature data). Support for optimising both SQ and MQ data >> simultaneously needs to be added. Currently relax only handles one >> type of dispersion data per data pipe. This should not be too hard to >> change. Such a change could allow CPMG-type and R1rho-type data to be >> analysed simultaneously as well. In each individual data combination >> case, a specific combined model such as 'SQ+MQ CR72' would need to be >> created. This model would be independent of the 'CR72' and 'MQ CR72' >> models, and the user will have to explicitly select it. >> >> The only change from the perspective of the user would the >> relax_disp.exp_type user function. This user function currently sets >> the experiment type for all data in the current data pipe. This needs >> to be changed to be similar to the relax_disp.cpmg_frq, >> relax_disp.relax_time, relax_disp.spin_lock_field, etc user functions, >> where the experiment type is associated with a spectrum ID. The GUI >> would be changed so that this user function is not presented when >> setting up a new analysis, but rather when the peak lists are being >> loaded. The GUI element displaying the experiment type would need to >> be removed and the data presented in the peak list GUI element >> instead. >> >> The backend changes would be more extensive. The following generator >> functions would need to be added to >> specific_analyses.relax_disp.disp_data: >> >> loop_exp() - for new usages. >> loop_exp_frq() - to replace calls to loop_frq(). >> loop_exp_frq_point() - to replace calls to loop_frq_point(). >> loop_exp_frq_point_time() - to replace calls to loop_frq_point_time(). >> >> The the code in specific_analyses.relax_disp and >> target_functions.relax_disp need to be modified around this new >> concept. I.e. a new top level looping needs to be inserted. The >> looping hierarchy from highest level to lowest would become: >> experiment type, magnetic field strength, dispersion point (CPMG >> frequency or spin-lock field strength), and finally relaxation time. >> The only difference to now is the highest level experiment type >> looping. >> >> The cdp.exp_type data structure will need to be converted into a >> dictionary where the keys are the spectrum IDs. >> >> >> 3) Test data. >> >> More of an issue is data! Test data is essential to be sure that the >> code is functional. And in relax it needs to be incorporated into a >> system test. The most important point is that the data needs to be >> independent of relax - the same code for fitting cannot be used to >> generate synthetic data. The more independence between relax and this >> test data, the better. >> >> Literature data for MQ data appears not to be available. It looks >> like corresponding authors would need to be emailed for access to the >> base data and numerical results. An alternative is provided by the >> Matlab software GUARDD. It has a module for simulating dispersion >> data >> (http://code.google.com/p/guardd/#Optimization_and_education_with_RD_Simulator). >> This could be used to generate the test data to be included with >> relax. Some test data is also provided by the program. This could >> also be used, but it suffers from the fact that the real parameter >> values are not known. But it can be used to directly compare relax >> and GUARDD. >> >> Regards, >> >> Edawrd >> > > > -- > Paul Schanda, Ph.D. > Biomolecular NMR group > Institut de Biologie Structurale Jean-Pierre Ebel (IBS) > 41, rue Jules Horowitz > F-38027 Grenoble > France > +33 438 78 95 55 > [email protected] > http://www.ibs.fr/groups/biomolecular-nmr-spectroscopy?lang=en > _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] 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
