Re: CST branch -- February 25, 2011 - 19:34

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
>>
>>
>