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 = "">
>>> >>> > 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
>>> >>
>>> >>
>>> >
>>
>>
>
Re: CST branch