Hi Edward. When I try to do a grid search, it does not initalize func_CR72_full in the target function? If I make import sys sys.exit() It does not stop? Only if I do a minimise, it stops? It is in specific_analyses/relax_disp/optimisation.py line 745 Inserting print model.func.im_func.__name__ gives func_CR72_full How does it know how to unpack and calculate? Best Troels 2014-06-06 12:32 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
Hi, That sounds good. Maybe it's best to have the number of fields and number of spins set to something different and not to 2? That way the unpacking is stressed as much as possible and there cannot be a accidental swap of the field and spin dimensions being unnoticed by the test. This is not likely, but I've encountered enough weird and supposedly impossible situations in the development of relax that it would not surprise me. Cheers, Edward On 6 June 2014 12:27, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx> wrote:Check. I am generating R2eff data for 3 fields, and 3 spins, for full model. I will put the data in test_suite/shared_data/dispersion/bug_22146_unpacking_r2a_r2b_cluster Best Troels 2014-06-06 12:11 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:Hi, Right, you have the 2 parameters in the self.num_spins*2 part. And I forgot about the parameters being different for each field. It would be good to then have a multi-field and multi-spin cluster system test to really make sure that relax operates correctly, especially with the data going into the target function and the subsequently unpacking the results into the relax data store. For example someone might modify the loop_parameters() function - this concept could be migrated into the specific API and converted into a common mechanism for all the analysis types as it is quite powerful - and they may not know that the change they just made broke code in the target_functions.relax_disp module. Cheers, Edward On 6 June 2014 12:05, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx>wrote:Hi Ed. The implementations needs: R20 = params[:self.end_index[1]].reshape(self.num_spins*2, self.num_frq) R20A = R20[::2].flatten() R20B = R20[1::2].flatten() 2014-06-06 11:55 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:The different unpacking implementations can be tested with the timeit Python module to see which is fastest (http://thread.gmane.org/gmane.science.nmr.relax.devel/5937/focus=6010).Cheers, Edward On 6 June 2014 11:53, Edward d'Auvergne <edward@xxxxxxxxxxxxx>wrote:Hi, In this case, I think 'num_frq' should be fixed to 2. Thisdimensioncorresponds to the parameters R20A and R20B so it is always fixedto2. Regards, Edward On 6 June 2014 11:51, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxxwrote:Hi. Another way is: ml = params[:end_index[1]].reshape(num_spins*2, num_frq) R20A = ml[::2].flatten() R20B = ml[1::2].flatten() Best Troels 2014-06-06 11:39 GMT+02:00 Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx>:There is no doubt that it is the unpacking of the R20A and R20Binthe target function. I was thinking of creating a function, which do the theunpacking.This unpacking function could then be tested with a unit test? What do you think? Where should I position such a function? Best Troels 2014-06-06 11:26 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:Hi Troels, The best way to handle this is to first create a unit test ofthespecific_analyses.relax_disp.parameters.disassemble_param_vector()where the problem is likely to be most easily found. I don't understand how this could be a problem as the assemble_param_vector() and disassemble_param_vector() functions both call the same loop_parameters() function for the ordering of the parameter values! Maybe the problem is in the unpacking of the parameter vector in the target functions themselves, for example in the full B14 model: def func_B14_full(self, params): """Target function for the Baldwin (2014) 2-site exact solution model for all time scales. This assumes that pA > pB, and hence this must be implemented as a constraint. @param params: The vector of parameter values. @type params: numpy rank-1 float array @return: The chi-squared value. @rtype: float """ # Scaling. if self.scaling_flag: params = dot(params, self.scaling_matrix) # Unpack the parameter values. R20A = params[:self.end_index[0]] R20B = params[self.end_index[0]:self.end_index[1]] dw = params[self.end_index[1]:self.end_index[2]] pA = params[self.end_index[2]] kex = params[self.end_index[2]+1] # Calculate and return the chi-squared value. return self.calc_B14_chi2(R20A=R20A, R20B=R20B, dw=dw, pA=pA, kex=kex) This R20A and R20B unpacking might be the failure point as this may not match the loop_parameters() function - which it must! Inanycase, having a unit or system test catch the problem would beveryuseful for the stability of the dispersion analysis in relax. A code example might be useful: R20_params = array([1, 2, 3, 4]) R20A, R20B = transpose(R20_params.reshape(2, 2) print(R20A) print(R20B) You should see that R20A is [1, 3], and R20B is [2, 4]. This is how the parameters are handled in the loop_parameters() functionwhichdefines the parameter vector in all parts of relax. There might be a quicker way to unpack the parameters, but such an idea could be used for the target functions. Cheers, Edward On 6 June 2014 11:08, Troels E. Linnet <NO-REPLY.INVALID-ADDRESS@xxxxxxx> wrote:URL: <http://gna.org/bugs/?22146> Summary: Unpacking of R2A and R2B isperformedwrong for clustered "full" dispersion models Project: relax Submitted by: tlinnet Submitted on: Fri 06 Jun 2014 09:08:58 AM UTC Category: relax's source code Specific analysis category: Relaxation dispersion Priority: 9 - Immediate Severity: 4 - Important Status: None Assigned to: None Originator Name: Originator Email: Open/Closed: Open Release: Repository: trunk Discussion Lock: Any Operating System: All systems _______________________________________________________ Details: The unpacking of the R2A and R2B parameters in the "full"modelis performed wrong. This will happen performing a clustered analysis, using one of the "full" models. This bug affect all analysis performed running with a "full" model, with clustered residues. The bug is located in the target function: ./target_functions/relax_disp.py For all the "func_MODEL_full", the unpacking of: R20A = params[:self.end_index[0]] R20B = params[self.end_index[0]:self.end_index[1]] This is wrong, since the "params" list, is ordered: [spin, spin, spin, [dw], pA, kex], where spin = [nr_frq*r2a, nr_frq*r2b] This ordering happens in: ./specific_analysis/relax_disp/parameters.py in the loop_parameters.py A possible solutions i shown below. This alter the unpacking of the parameters. An example of profiling_cr72.py is attached. This can be downloaded, and run in base folder of relax: ./profiling_cr72.py . This is with 3 frq, and 3 spins. The current implementations would unpack: ('R20A', array([ 2., 2., 2., 4., 4., 4., 12.,12.,12.]), 9) ('R20B', array([ 14., 14., 14., 22., 22., 22., 24.,24.,24.]), 9) R2A is 2, 12, 22 for the spins 0-3 R2B is, 4, 14, 24 for the spins 0-3 The suggested unpacking loop, unpacks to: ('R20A', array([ 2., 2., 2., 12., 12., 12., 22.,22.,22.]), 9) ('R20B', array([ 4., 4., 4., 14., 14., 14., 24.,24.,24.]), 9) ------- from numpy import array, concatenate, delete, index_exp import numpy p = array([ 1.000000000000000e+01, 1.000000000000000e+01, 1.100000000000000e+01 , 1.100000000000000e+01, 1.000000000000000e+01, 1.000000000000000e+01 , 1.100000000000000e+01, 1.100000000000000e+01, 1.000000000000000e+00 , 1.000000000000000e+00, 9.000000000000000e-01, 1.000000000000000e+03]) e = [4, 8, 10] # Now r2a = p[:e[0]] print r2a r2b = p[e[0]:e[1]] print r2b dw = p[e[1]:e[2]] print dw pA = p[e[2]] print pA kex = p[e[2]+1] print kex print "new" ns = 2 nf = 2 ml = p[:e[1]] R20A = array([]) R20B = array([]) for i in range(0, ns): # Array sorted per [spin, spin, spin], where spin = [nr_frq*r2a, nr_frq*r2b] spin_AB = ml[:nf*2] ml = delete(ml, numpy.s_[:nf*2]) R20A = concatenate([R20A, spin_AB[:nf] ]) R20B = concatenate([R20B, spin_AB[nf:] ]) print R20A print R20B print dw print pA print kex _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 06 Jun 2014 09:08:58 AM UTC Name: profiling_cr72.py Size: 17kB By: tlinnet <http://gna.org/bugs/download.php?file_id=20938> _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?22146> _______________________________________________ Message sent via/by Gna! http://gna.org/ _______________________________________________ relax (http://www.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