Hi, It's too complex to set up a unit test. A unit test is to check individual functions - it's really on the low level of the functions, methods, etc. If you are using the relax data store, then this is more suited for a system test. So such a test would be best as a system test. You could even check for the values in one of the pre-existing system tests. That would be the easiest solution, and it wouldn't add any extra time to the test suite. There is nothing a new test would add, as all the current tests would be sufficient for full coverage of any auxiliary parameters added.
Regards, Edward On 9 September 2013 21:25, Troels Emtekær Linnet <[email protected]> wrote: > Hi Edward. > > Where should I start write a test for the conversion? > > Should it be a system or unit test ? > > And should I load a dataset, minimize it, and then see > if the converted parameter is available for the model? > > Best > Troels > > > > Troels Emtekær Linnet > > > 2013/9/9 Edward d'Auvergne <[email protected]>: >> Hi. >> >>> There is an explanation for everything, including user errors. :-) >> >> I'd call this more developer errors ;) Talking about development, I >> will soon ask the other relax developers about you joining the >> development team. This will have to wait a little while as I am on >> holidays for about 3 weeks starting from this weekend. >> >> >>> I have analysed the 0.48 M GuaHCl dataset (the folded protein), and so >>> this is not comparable to the >>> 1M GuaHcl (intermediate between folded/unfolded) dataset, which is >>> shown in the figures in the paper. >>> >>> So, I got the original datapoints for figure 3, which shows the >>> ln(k_a) per GuaHCl. >>> And now k_a fits perfect for 0.48 M. >>> >>> And I have today analysed the 1M dataset. >>> >>> Everything matches until first digit, so I am satisfied. >> >> This sounds great! The model is so incredibly simple that finding out >> that a data mix up was the source of the problem is quite a relief. >> >> >>> So, I will soon send a swarm of patches to include this dataset. >> >> All patched >> (http://thread.gmane.org/gmane.science.nmr.relax.devel/4372/focus=4563). >> >> >>> Thanks for looking! >>> >>> I will look into the tsmfk01 code to speed it up. >> >> No problems. I look forward to seeing your solutions. >> >> >>> To compare to the numerical methods, you mentioned that one could make >>> auto conversion of the >>> parameters? >>> >>> So could k_AB be calculated for the numerical methods, so: >>> k_AB = kex*(1-pA) >> >> Yes, this can be done. The complication is handling the Monte Carlo >> simulations, specifically the parameter error estimate calculation at >> the end of all simulations. You can have a go at this yourself, if >> you wish. The key is to look for where the 'tex' or 'pB' parameters >> are handled, as these are not parameters in most of the dispersion >> models, and to study this code. These two parameters will be handled >> as you wish k_AB to be. If k_AB is calculated, then so should k_BA. >> Maybe phi_ex should also be added to this list of 'auxiliary' >> parameters so that the numeric models can be easily compared to the >> fast exchange models. Are there any other auxiliary parameters you >> can think of? What about the alpha factor which determines if the >> exchange is fast, slow or intermediate? >> >> Cheers, >> >> Edward _______________________________________________ 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
