I should have read the text of the commit message more carefully :) Bye,
Edward On 25 February 2011 19:46, Edward d'Auvergne <edw...@nmr-relax.com> 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.kadera...@gmail.com> 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 <edw...@nmr-relax.com> 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 <edw...@nmr-relax.com> 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.kadera...@gmail.com> >>> > 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 <edw...@nmr-relax.com> >>> >> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Please see below: >>> >>> >>> >>> >>> >>> On 24 February 2011 10:02, Pavel Kaderavek <pavel.kadera...@gmail.com> >>> >>> 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_prime >>> >>> >>> >>> This 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 >>> >> >>> >> >>> > >> >> > _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list relax-devel@gna.org 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
