Re: CST branchRe: CST branchI 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