Re: CST branchRe: CST branchHi, This patch was also ok, and is now applied. Cheers, Edward On 1 March 2011 12:54, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:
This change is related to the task #6397 (https://gna.org/task/?6397) kada _at_ chemi _dot_ muni _dot_ cz https://mail.gna.org/public/relax-devel/2011-03/msg00001.html https://gna.org/task/download.php?file_id=12603 This patch includes change in the functions calc_(d,d2)noe in a file maths_fns/ri.py , where (d,d2)ri_prime was renamed to (d,d2)ri. This patch covers also the related change of names in the function init_res_r1_data (class Mf, maths_fns/mf.py), where the variables are initialized. On 1 March 2011 10:36, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, The renaming should be fine. I see no reason at the moment why we cannot perform an in place replacement of sigma_NOE with the NOE value inside the data[x][y].ri data structure. If sigma_NOE is needed in the future, then the person who needs it can recalculate it from the NOE and R1. Cheers, Edward On 1 March 2011 10:22, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:Hi, Yes, you are right. It might be included in some of the following patches. First, we would like to discuss changes in the next patch, where we would like to replace variable name ri_prime in functions calc_(d,d2)noe in a file maths_fns/ri.py to follow the changes in the patch: https://mail.gna.org/public/relax-devel/2011-02/msg00081.html It was pre-discussed in: https://mail.gna.org/public/relax-devel/2011-02/msg00084.html The changes also imply renaming of variables r1_data.(d,d2)ri_prime to r1_data.(d,d2)ri in the initialization function init_res_r1_data (class Mf, maths_fns/mf.py). Best regards, Pavel On 1 March 2011 09:59, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, The patch looks good, I've now applied it. In the future, you might find that the self.diff_data structure does not need to be passed into self.init_spin_data(). Cheers, Edward On 28 February 2011 16:51, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:This change is related to the task #6397 (https://gna.org/task/?6397) kada _at_ chemi _dot_ muni _dot_ cz https://mail.gna.org/public/relax-devel/2011-02/msg00088.html https://gna.org/task/download.php?file_id=12598 This patch includes change in init_res_data function of class Mf in a file maths_fns/mf.py. The function is split into init_interaction_data and init_spin_data. The initializations of data.ri_prime, data.dri_prime, and data.d2ri_prime are excluded. Calls for both newly introduced functions are incorporated in the patch. On 25 February 2011 20:38, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, I agree, these are good designs. The init_res_data name is a relic of old code from relax 1.2 when only single residues were handled and not individual and multiple spins per residue. It should have been renamed to init_spin_data. Cheers, Edward On 25 February 2011 20:18, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:Hi, We would like to discuss the initialization of the spin and interaction data (Spin_object, Data) in class Mf (maths_fns/mf.py). Currently, there is a function init_res_data which initializes variables in container Data. The container Data is now redesigned to store only the interaction specific information and the spin specific data were moved to Spin_object. We suggest to rename init_res_data to init_interaction_data and move spin data initialization parts to a newly created function init_spin_data. The function init_interaction_dat will be called at the same place as the original init_res_data, while init_spin_data will be called just after the Spin_object is appended to self.data. Best regards, Pavel On 25 February 2011 19:48, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:I should have read the text of the commit message more carefully :) Bye, Edward On 25 February 2011 19:46, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Ah, this will also work. I didn't release that one of the next changes would be the in place replacement of sigma_noe by the NOE value inside maths_fns/ri.py. Ok, I'll commit the patch. Cheers, Edward On 25 February 2011 19:34, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:Hi, maybe we misunderstood some parts of the code, but the data.ri_prime seems to be used only in maths_fns/ri.py to calculate NOE value. Therefore, it should be possible to replace data.ri_prime by data.ri directly and later change function defined in ri.py to use data.ri instead of data.ri_prime. original code of maths_fns/ri.py: def calc_noe(data, i, frq_num, get_r1, params): """Calculate the NOE value. Half this code needs to be shifted into the function initialisation code. """ # Get the r1 value either from data.ri_prime or by calculation if the value is not in data.ri_prime data.r1[i] = get_r1[i](data, i, frq_num, params) # Calculate the NOE. if data.r1[i] == 0.0 and data.ri_prime[i] == 0.0: data.ri[i] = 1.0 elif data.r1[i] == 0.0: data.ri[i] = 1e99 else: data.ri[i] = 1.0 + data.g_ratio*(data.ri_prime[i] / data.r1[i]) modified version: def calc_noe(data, i, frq_num, get_r1, params): """Calculate the NOE value. Half this code needs to be shifted into the function initialisation code. """ # Get the r1 value either from data.ri_prime or by calculation if the value is not in data.ri_prime data.r1[i] = get_r1[i](data, i, frq_num, params) # Calculate the NOE. if data.r1[i] == 0.0 and data.ri[i] == 0.0: data.ri[i] = 1.0 elif data.r1[i] == 0.0: data.ri[i] = 1e99 else: data.ri[i] = 1.0 + data.g_ratio*(data.ri[i] / data.r1[i]) the data structure data.ri is created during the initialization and data.ri is calculated by function calc_noe. Therefore we do not see a reason to keep this line in the code: data.ri = data.ri_prime * 1.0 since data.ri would be calculated by cumulative summation as we suggested. Is our understanding correct? Best regards, Pavel On 25 February 2011 18:16, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, The line: data.ri = data.ri_prime * 1.0 is also quite important. This creates a new data structure data.ri initialised to the values of data.ri_prime. These lines are probably still necessary. Cheers, Edward On 25 February 2011 18:14, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, I've just been looking at this patch, and it seems to have a problem. The new lines are: data.ri = data.ri + data[j].create_ri_prime(data[j]) But this is ri_prime. data.ri is created later on with the call to data.create_ri. Should this be: data.ri_prime = data.ri_prime + data[j].create_ri_prime(data[j]) Regards, Edward On 25 February 2011 18:09, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:This change is related to the task #6397 (https://gna.org/task/?6397) kada _at_ chemi _dot_ muni _dot_ cz https://mail.gna.org/public/relax-devel/2011-02/msg00076.html https://gna.org/support/download.php?file_id=12556 This patch includes change in func_mf, func_local_tm, func_diff, func_all, dfunc_mf, dfunc_local_tm, dfunc_diff, dfunc_all, d2func_mf, d2func_local_tm, d2func_diff, d2func_all functions of class Mf in a file maths_fns/mf.py. The functions were modified in order to handle data for more interactions. Due to the equality of (d,d2)ri and (d,d2)ri_prime variables, the (d,d2)ri_prime were replaced by (d,d2)ri and the equality was removed. Moreover, (d,d2)ri was redefined as a cumulative sum of individual interaction contributions to the total relaxation rate or corresponding derivatives. On 24 February 2011 12:26, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:Hi, Please see below: On 24 February 2011 10:02, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:Hi, We realized a problem during the preparation of the following patch. Currently, it is impossible to initialize variables in the originally suggested way: data = self.data[0] data.ri_prime = 0.0 in the function func_mf (maths_fns/mf.py) and other similar functions (func_local_tm, func_diff, func_all, and their equivalents for a first and second derivatives).Ah, yes. 'data' here is a list rather than a container, so you can't do this. If you like, what I can do is create a special list-like object for this. The you can access list elements, but also place variables inside it. The other problem is that ri_prime returned by maths_fns.ri_prime.func_ri_prime() is not a number but a numpy array. Its dimensions are Nx1, where N is the number of relaxation data points. So the initialisation will have to be at the very start rather than in the func_mf() methods, and it needs to be initialised to the correct numpy object using something like 'zeros(num_ri[i], float64)'. The dri_prime, d2ri_prime, ri, dri, and d2ri prime will have similar problems. I would suggest that 'ri_prime' does not need to be summed, but only 'ri'. Or am I missing something? The difference between ri and ri_prime is that ri contains the steady-state NOE whereas ri_prime contains sigma_NOE. Do we need to store and sum ri_prime at all?It is not possible because of the approved changes of __init__ function in the class Mf (file maths_fns/mf.py). The array used to store data is created in the following way: self.data = [] for i in xrange(self.num_spins): ... self.data.append([]) ... # Loop over the relaxation interactions. for j in xrange(self.num_interactions[i]): self.data[i].append(Data()) # This is a list dedicated for the storage of interaction specific parameters (i.e. type of interaction, internuclei distance, ...) self.data[i][j].interactions=interactions[i][j] self.data[i][j].internuclei_distance=internuclei_distance[i][j] ... Thus, the list for a storage of spin specific data does not exist and the suggested variable location does not exist: self.data[0].ri_primeThis can be created, if I make this special Python list-like object. There is already one special object, the Data class at the very end of the file. I can create a list-like object here as well, and initialise each spin object to this. Ok, I've just added this code in r12618. This should fix the problem and not cause too many problems with your current code.We found some possible ways to solve the problem. However we do not think, they are ideal. First, we can add for each spin a new list except those which store the interaction specific data. Data_spin list would be at the beginning of the array and therefore every loop over interactions in the code has to keep it in mind and start from index 1 not 0 to avoid Data_spin list. The second possibility is based on the idea to declare for each spin a class Spin_data. The Spin_data would contain all spin specific variables (ri_prime, chi2, ...) and also a class Data which would contain interaction specific data. What do you think about these suggestions? We will be glad for any better suggestion, than ours.I have taken your second idea, but it is inbuilt into the self.data[i] structure itself rather than a separate object inside self.data. I hope this solution will be ok. Cheers, Edward